How Hard is it to Find (Honest) Witnesses?
Isaac Goldstein, Tsvi Kopelowitz, Moshe Lewenstein, Ely Porat

TL;DR
This paper introduces a framework based on the 3SUM conjecture for proving conditional lower bounds by efficiently representing and enumerating witnesses (candidate solutions) to problems, impacting various computational problems.
Contribution
The paper presents a novel framework that leverages hashing and encoding to relate witness enumeration to lower bounds, applicable to multiple problem domains.
Findings
Framework establishes 3SUM-hardness for decision problems
Enables lower bounds for convolution, matrix multiplication, and string problems
Uses witness enumeration to connect problem complexity with 3SUM conjecture
Abstract
In recent years much effort was put into developing polynomial-time conditional lower bounds for algorithms and data structures in both static and dynamic settings. Along these lines we suggest a framework for proving conditional lower bounds based on the well-known 3SUM conjecture. Our framework creates a \emph{compact representation} of an instance of the 3SUM problem using hashing and domain specific encoding. This compact representation admits false solutions to the original 3SUM problem instance which we reveal and eliminate until we find a true solution. In other words, from all \emph{witnesses} (candidate solutions) we figure out if an \emph{honest} one (a true solution) exists. This enumeration of witnesses is used to prove conditional lower bound on \emph{reporting} problems that generate all witnesses. In turn, these reporting problems are reduced to various decision problems.…
| Problem | Type | Preprocessing Time | Query Time | Reporting Time | Remarks |
| Convolution Witnesses | Reporting | Theorem 4.2 | |||
| Partial Convolution | Decision | — | — | Theorem 5.1 Sparse input: ; Sparse required output: | |
| Partial Convolution Indexing | Decision | — | Theorem 5.3 Sparse input: ; Sparse required output: | ||
| Partial Matrix Multiplication | Decision | — | — | Theorem 6.1 Sparse input: ; Sparse required output: | |
| Partial Matrix Multiplication Indexing | Decision | — | Theorem 6.3 Sparse input: ; Sparse required output: ; | ||
| Histogram Reporting | Reporting | Theorem 7.3 alphabet size: ; | |||
| Histogram Indexing | Decision | — | Theorem 7.6 alphabet size: ; |
| Amir et al. [5] | This Paper | Remarks | |
|---|---|---|---|
| CLB for preprocessing time | alphabet size: ; | ||
| CLB for query time | alphabet size: ; | ||
| Hardness assumption | Strong 3SUM conjecture | Standard 3SUM conjecture | |
| CLBs with full tradeoff between preprocessing and query time for every alphabet size. | No | Yes | |
| Separation between binary alphabet and alphabet of size>2 for subquadratic preprocessing time and query time. | No | Yes | |
| CLBs for the reporting version of histogram indexing. | No | Yes |
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
How Hard is it to Find (Honest) Witnesses?
Isaac Goldstein This research is supported by the Adams Foundation of the Israel Academy of Sciences and Humanities Bar-Ilan University
{goldshi,moshe,porately}@cs.biu.ac.il
Tsvi Kopelowitz This research is supported by NSF grants CCF-1217338, CNS-1318294, and CCF-1514383 University of Michigan
Moshe Lewenstein This research is supported by a BSF grant 2010437 and a GIF grant 1147/2011. Bar-Ilan University
{goldshi,moshe,porately}@cs.biu.ac.il
Ely Porat
Bar-Ilan University
{goldshi,moshe,porately}@cs.biu.ac.il
Abstract
In recent years much effort was put into developing polynomial-time conditional lower bounds for algorithms and data structures in both static and dynamic settings. Along these lines we suggest a framework for proving conditional lower bounds based on the well-known 3SUM conjecture. Our framework creates a compact representation of an instance of the 3SUM problem using hashing and domain specific encoding. This compact representation admits false solutions to the original 3SUM problem instance which we reveal and eliminate until we find a true solution. In other words, from all witnesses (candidate solutions) we figure out if an honest one (a true solution) exists. This enumeration of witnesses is used to prove conditional lower bound on reporting problems that generate all witnesses. In turn, these reporting problems are reduced to various decision problems. These help to enumerate the witnesses by constructing appropriate search data structures. Hence, 3SUM-hardness of the decision problems is deduced.
We utilize this framework to show conditional lower bounds for several variants of convolutions, matrix multiplication and string problems. Our framework uses a strong connection between all of these problems and the ability to find witnesses.
Specifically, we prove conditional lower bounds for computing partial outputs of convolutions and matrix multiplication for sparse inputs. These problems are inspired by the open question raised by Muthukrishnan 20 years ago [22]. The lower bounds we show rule out the possibility (unless the 3SUM conjecture is false) that almost linear time solutions to sparse input-output convolutions or matrix multiplications exist. This is in contrast to standard convolutions and matrix multiplications that have, or assumed to have, almost linear solutions.
Moreover, we improve upon the conditional lower bounds of Amir et al. [5] for histogram indexing, a problem that has been of much interest recently. The conditional lower bounds we show apply for both reporting and decision variants. For the well-studied decision variant, we show a full tradeoff between preprocessing and query time for every alphabet size > 2. At an extreme, this implies that no solution to this problem exists with subquadratic preprocessing time and query time for every alphabet size > 2, unless the 3SUM conjecture is false. This is in contrast to a recent result by Chan and Lewenstein [9] for a binary alphabet.
While these specific applications are used to demonstrate the techniques of our framework, we believe that this novel framework is useful for many other problems as well.
1 Introduction
In recent years much effort has been invested towards developing polynomial time lower bounds for algorithms and data structures in both static and dynamic settings. This effort is directed towards obtaining a better understanding of the complexity class for well-studied problems which seem hard in the polynomial sense. The seminal paper by Gajentaan and Overmars [13] set the stage for this approach by proving lower bounds for many problems in computational geometry conditioned on the 3SUM conjecture. In the 3SUM problem we are given a set of integers and we need to establish if there are such that . This problem has a simple algorithm (and some poly-logarithmic improvements in [6, 17]) but no truly subquadratic algorithm is known, where truly subquadratic means for some . The 3SUM conjecture states that no truly subquadratic algorithm exists for the 3SUM problem. Based on this conjecture, there has been a recent extensive line of work establishing conditional lower bounds (CLBs) for many problems in a variety of fields other than computational geometry, including many interesting dynamic problems, see e.g. [1, 2, 3, 4, 19, 23].
1.1 Decision and Reporting Problems
Algorithmic problems come in many flavors. The classic one is the decision variant. In this variant, we are given an instance of a problem and we are required to decide if it has some property or not. Some examples include: (1) given a 3-CNF formula we may be interested in deciding if it satisfiable by some truth assignment; (2) given a bipartite graph we may be interested in deciding if the graph has a perfect matching; (3) given a text and a pattern we may be interested in deciding if occurs in . It is well-known that the first example is NP-complete while the two others are in P. An instance that has the property in question has at least one witness that proves the existence of the property. In the examples above a witness is: (1) a satisfying assignment; (2) a perfect matching in the graph; (3) a position of an occurrence of in . Sometimes, we are not only interested in understanding if a witness exists, but rather we wish to enumerate all of the witnesses. This is the reporting variant of the problem. In the examples mentioned above the goal of the reporting variant is to: (1) enumerate all satisfying assignments; (2) enumerate all perfect matchings; (3) enumerate all occurrences of in . For the first two examples it is known from complexity theory that it is most likely hard to count the number of witnesses (not to mention reporting them) (these are #P-complete problems), while the third example can be solved by classic linear time algorithms.
In this paper we investigate the interplay between the decision and reporting variants of algorithmic problems and present a systematic framework that is used for proving CLBs for these variants. We expect this framework to be useful for proving CLBs on other problems not considered here.
1.2 Our Framework
We introduce and follow a framework that shows 3SUM-hardness of decision problems via their reporting versions. The high-level idea is to reduce an instance of 3SUM to an instance of a reporting problem, and then reduce the instance of a reporting problem to several instances of its decision version using a sophisticated search structure. The outline of this framework is described next.
- •
Compact Representation. One of the difficulties in proving CLBs based on the 3SUM conjecture is that the input universe for 3SUM could be too large for accommodating a reduction to a certain problem. To tackle this, we embed the universe using special hashing techniques. This is sometimes coupled with a secondary problem-specific encoding scheme in order to match the problem at hand.
- •
Reporting. The embedding in the first step may introduce false-positives. To tackle this, we report all the candidate solutions (witnesses) for the embedded 3SUM instance, in order to verify if a true solution (an honest witness) to 3SUM really exists. This is where we are able to say something about the difficulty of solving reporting problems. This is done by reducing the embedded 3SUM instance to an instance of such a reporting problem, if it provides an efficient way to find all the false-positives. In some cases, such reductions reveal tradeoff relationships between the preprocessing time and reporting/query time.
- •
Reporting via Decision. In this step the goal is to establish 3SUM-hardness of a decision problem. To do so we reduce an instance of the reporting version of the problem to instances of the decision version by creating a data structure on top of the many instances of the decision version. This data structure allows us to efficiently report all of the elements in the output of the instance of the reporting version. By constructing the data structure in different ways we obtain varying CLBs for the decision variants depending on the specific structure that we use.
By following this route we introduce new CLBs for some important problems which are discussed in detail in Section 2. We point out that the embedding in the first step follows along the lines of [23] and [19]. However, in some cases we also add an additional encoding scheme to fit the needs of the specific problem at hand.
Implications. In Section 2 we discuss three applications from two different domains which utilize our framework for proving CLBs, thereby demonstrating the usefulness of our framework. Table 1 in Appendix A summarizes these results. Of particular interest are new results on Histogram Indexing (defined in Section 2) which, together with the algorithm of [9], demonstrate a sharp separation when allowing truly subquadratic preprocessing time between binary and trinary alphabet settings. Moreover, our framework is the first to obtain a CLB for the reporting version, which, as opposed to the decision variant, also holds for the binary alphabet case. See Table 2 in Appendix A.
2 Applications
**Convolution Problems **
The convolution of two vectors is a vector , such that for . Computing the convolution of and takes time using the celebrated FFT algorithm. Convolutions are used extensively in many areas including signal processing, communications, image compression, pattern matching, etc. A convolution witness for the th entry in is a pair such that and . In other words, the witnesses of entry in are all values that contribute a non-zero value to the summation . The first convolution problem we consider is the convolution witnesses problem which is defined as follows.
Definition 2.1**.**
In the convolution witnesses problem we preprocess two vectors and their convolution vector , so that given a query integer , we list all convolution witnesses of index in .
We prove the following CLB for the convolution witnesses problem that holds even if and are binary vectors and all numbers in are non-negative integers.
Theorem 1**.**
Assume the 3SUM conjecture is true. Then for any constant , there is no algorithm solving the convolution witnesses problem with expected preprocessing time and expected amortized query time per witness.
Theorem 1 implies that when using only truly subquadratic preprocessing time one is required to spend a significant polynomial amount of time on every single witness. In particular, this means that, assuming the 3SUM conjecture, one cannot expect to find witnesses much faster than following the naive algorithm for computing convolution naïvely according to the convolution definition. This is in contrast to the decision version of the problem, where we only ask if a witness exists. This variant is easily solved using constant query time after a near linear time preprocessing procedure (computing the convolution itself).
Another variation of the convolution problem which we consider is the sparse convolution problem. There are two different problems named sparse convolution, both appearing as open questions in a paper by Muthukrishnan [22]. In the first, which is now well understood, we are given Boolean vectors and of lengths and , where . There are ones in , ones in and ones in , where is the Boolean convolution vector of and . The goal is to report the non-zero elements in in time. This problem has been extensively studied, and the goal has been achieved; see for example [9, 11, 15]. The second variant which we call partial convolutions is as follows.
Definition 2.2**.**
The partial convolution problem on two vectors and of real numbers (of length and respectively, where ) and a set of indices is to compute, for each , the value of the -th element in the convolution of and .
Muthukrishnan in [22] asked if it is possible to compute a partial convolution significantly faster than the time needed to compute a (classic) convolution. We prove a CLB based on the 3SUM conjecture, that holds also for the special case of Boolean vectors, and, therefore, also for the special case in which we only want to know if the output values at indices in are zero or more. Moreover, we focus on the important variant of this problem that deals with the case where the two input vectors have only ones and are both given implicitly (specifying only the indices of the ones). Our results also extend to the indexing version of the partial convolution problem, which we call the partial convolution indexing problem, and is defined as follows.
Definition 2.3**.**
The partial convolution indexing problem is to preprocess an -length vector of real numbers and a set of indices to support the following queries: given an -length vector () of real numbers, for each compute the value of the -th element of the convolution of and .
Once again this variant already relevant when the input is Boolean and sparse, i.e. and have ones and are represented implicitly by specifying their indices.
We prove the following CLBs for these problems with the help of our framework.
Theorem 2**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial convolution problem with time, even if and the number of ones in both input vectors are less than .
Theorem 3**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial convolution indexing problem with preprocessing time and query time, even if both and the number of ones of the input vectors are .
As mentioned above, the convolution of vectors of length can be computed in time with the FFT algorithm. However, in the partial convolution problem and partial convolution indexing problem, despite the input vectors being sparse and represented sparsely (specifying only the indices of the ones in each vector), and despite the portion of the output we need to compute being sparse (), no linear time algorithm (in ) exists, unless the 3SUM conjecture is false.
Notice that the partial convolution problem and its indexing variant are decision problems, since they require a decision for each location , whether or not. This is in contrast to the convolution witnesses problem, which is a reporting problem, as it requires the reporting of all of the witnesses for .
To prove CLBs for the convolution problems we follow our framework. That is, we first use a hash function to embed a 3SUM instance to a smaller universe. This mapping introduces false-positives, which we enumerate by utilizing the reporting problem of convolution witnesses. To solve the reporting version we reduce it to several instances of a decision problem, partial convolution or its indexing variant, by constructing a suitable data structure. Tying it all together leads to CLBs for both the reporting and decision problems.
**Matrix Problems **
We also present some similar CLBs for matrices.
Definition 2.4**.**
The partial matrix multiplication problem on two matrices and of real numbers and a set of entries is to compute, for each , the value .
The indexing variant of this problem is defined as follows.
Definition 2.5**.**
The partial matrix multiplication indexing problem is to preprocess an matrix of real numbers and a collection of sets of entries, where , so that given a sequence of matrices of real numbers, we enumerate the entries of that correspond to .
For let . We prove the following CLBs, which hold also for the special case of Boolean multiplication assuming that the input is given implicitly by specifying only the indices of the ones.
Theorem 4**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial matrix multiplication problem running in expected time, even if and the number of ones in the input matrices is .
Theorem 5**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial matrix multiplication indexing problem with preprocessing time and query time.
Matrix multiplication, and in particular Boolean matrix multiplication, can be solved in time, where [14, 25]. Many researchers believe that the true value of is . This belief implies that the running time for computing the product of two Boolean matrices is proportional to the size of the input matrices and the resulting output. However, our results demonstrate that such a result is unlikely to exist for sparse versions of the problem, where the number of ones in the matrices is and we are interested in only a partial output matrix (only entries of the matrix product).
To prove Theorem 4 and 5 we follow our framework. The process is very similar to the path for proving CLBs for convolution problems. In fact, instead of considering a reporting version of the partial matrix multiplication problem for proving these CLBs, we once again utilize the reporting problem of convolution witnesses. However, this time we transform the convolution witnesses to the matrix multiplication problems using a more elaborate data structure. The main difficulty in this transformation is to guarantee the sparsity of both the input and the required output. This transformation illustrates how a reporting version of a problem can be used to prove CLBs for decision versions of other problems, by changing the way we look for honest witnesses.
**String Problems **
Another application of our framework, which is seemingly unrelated to the previous two, is the problem of histogram indexing. A histogram, also called a Parikh vector, of a string over alphabet is a -length vector containing the character count of . For example, for the histogram is .
Definition 2.6**.**
In the histogram indexing problem we preprocess a string to support the following queries: given a query Parikh vector , return whether there is a substring of such that .
Definition 2.7**.**
In the histogram indexing reporting problem we preprocess a string to support the following queries: given a query Parikh vector , report indices of at which a substring of begins such that .
The problem of histogram indexing (not the reporting version) is sometimes called jumbled indexing. It has received much attention in recent years. For example, for binary alphabets - that is histograms of length 2 - there is a straightforward algorithm with preprocessing time and constant query time, see [10]. Burcsi et al. [8] and Moosa and Rahman [20] improved the preprocessing time to . Using the four-Russian trick a further improvement was achieved by Moosa and Rahman [21]. Then, using a connection to the recent improvement of all-pairs-shortest path by Williams [24], as observed by Bremner et al. [7] and by Hermelin et al. [16], the preprocessing time was further reduced to . Finally, Chan and Lewenstein [9] presented an preprocessing time algorithm for the problem with constant query time. For non-binary alphabets some progress was achieved in the work by Kociumaka et al. [18] and even further achievement was shown in [9]. On the negative side, some CLBs were recently shown by Amir et al. [5].
We follow our framework and first obtain CLBs for the reporting version of histogram indexing. This is the first time CLBs are shown for the reporting version. Moreover, these CLBs apply to binary alphabets, as opposed to the decision version in which there currently is no CLB known for binary alphabets. The CLBs for the reporting version admit a full tradeoff between preprocessing and query time. For the decision variant, we improve upon the CLB by Amir et al. [5] by presenting full-tradeoffs between preprocessing and query time based on the standard 3SUM conjecture. Specifically, our new CLB implies that no solution to the histogram indexing problem exists with subquadratic preprocessing time and query time for every alphabet size bigger than 2, unless the 3SUM conjecture is false. This demonstrates a sharp separation between binary and trinary alphabets, since Chan and Lewenstein [9] introduced an algorithm for histogram indexing on binary alphabets with preprocessing time and constant query time. A complete comparison of our results and the results by Amir et al. [5] appears in Table 2 in Appendix A.
The CLBs are summarized by the following theorems.
Theorem 6**.**
Assume the 3SUM conjecture is true. Then the histogram reporting problem for an -length string and constant alphabet size cannot be solved using preprocessing time, query time and reporting time per item, for any .
Theorem 7**.**
Assume the 3SUM conjecture holds. Then the histogram indexing problem for a string of length and constant alphabet size cannot be solved with preprocessing time and query time.
The main structure of these proofs follows our framework. We first embed a 3SUM instance and encode it in a string with limited length. We then report the false-positives using the reporting variant of the histogram indexing problem, which implies CLBs for this variant. Finally, we reduce the reporting version to the decision version thereby obtaining CLBs for the decision version. The reduction utilizes a sophisticated data structure for reporting witnesses using many instances of the decision version.
3 Preliminaries
In the basic 3SUM problem we are given a set of integers and we need to answer whether there are such that . In a common variant of the classic problem, which we also denote by 3SUM, three arrays and are given and we need to answer whether there are such that . Both versions have the same computational cost (see [13]). There are some other variants of the 3SUM problem shown to be as hard as 3SUM up to poly-logarithmic factors. One such variant is Convolution3SUM, shown to be hard by Pǎtraşcu [23], see also [19]. In Convolution3SUM is an ordered set and we need to answer whether there exist indices such that . We also define DiffConv3SUM, in which we are given an ordered set and we need to verify whether there exists such that . It is easy to see that this is equivalent to Convolution3SUM.
Let be a family of hash functions from . is called linear if for any and any , we have . is called almost-linear if for any and any , we have either , or , where is an integer that depends only on the choice of . For a function and a set where , we say that is an overflowed value of if . is called almost-balanced if for a random and any set where , the expected number of elements from that are mapped to overflowed values is . See [19] for constructions of families that are almost-linear and almost-balanced (see also [6, 12]).
For simplicity of presentation, and following the footsteps of previous papers that have used such families of functions [6, 23], we assume for the rest of the paper that almost linearity implies that for any and any we have . There are actually two assumptions taking place here. The first is that there is only one option of so-called linearity. Overcoming this assumption imposes only a constant factor overhead. The second assumption is that . However, the constant only affects offsets in our algorithm in a straightforward and not meaningful way, so we drop it in order to avoid clutter in our presentation.
4 Convolution Witnesses
We first prove a CLB for the convolution witnesses problem. We begin with a lemma which has elements from the proof of Pǎtraşcu’s reduction [23] and from [6]. However, the lemma diverges from [23] by treating the hashed subsets differently. Specifically, many special 3SUM subproblems are created and then reduced to convolution witnesses.
We say that a binary vector of length is -sparse if it contains at most ’s. An instance of convolution witnesses problem is -sparse if and are both of length and -sparse.
Lemma 1**.**
Let sequence be an instance of Convolution3SUM. Let , where is a constant. There exists a truly subquadratic reduction from the instance to -sparse instances of convolution witnesses problem for which we need to report witnesses (over all instances).
Proof 4.1**.**
We use an almost-linear, almost-balanced, hash function and create buckets where each contains the indices of all elements for which . Since is almost-balanced the expected overall number of elements in buckets with more than elements is . For each index in an overflowed bucket, we verify whether for every other in time. Hence, we verify whether any index in an overflowed bucket is part of a Convolution3SUM solution in expected time. Since the expected time is truly subquadratic time.
We now assume that every bucket contains at most elements. From the properties of almost-linear hashing, if then . Hence, if then implies that .
Every three buckets form an instance of 3SUM and are uniquely defined by and . Hence, there are 3SUM subproblems each on elements from the small universe . However, may generate false positives. So, we must be able to verify that any 3SUM solution (a witness) for any instance is indeed a solution (an honest witness) for the problem on . The number of false positives is expected to be over all instances, see [6]. So, we need an efficient tool to report each such witness in order to be able to solve Convolution3SUM.
To obtain such a tool, we reduce the problem to the convolution setting in the following way. We generate a characteristic vector of length for every set ( if and otherwise, for ). This vector will be -sparse, since . Note that: . Now, for each pair of vectors, and , we generate their convolution. Let be the convolution of and , and let . If , then we need to extract the witnesses of . For each witness we check whether . We note that if, while verifying, we discover that the overall number of the false-positives exceeds expectation (, for some constant ) by more than twice we rehash.
Thus, we see that Convolution3SUM can be solved by generating -sparse instances of convolution witnesses problem. These instances are computed in time, which is truly subquadratic as for .
It now follows that:
Theorem 4.2**.**
Assume the 3SUM conjecture is true. Then for any constant , there is no algorithm solving the convolution witnesses problem with expected preprocessing time and expected amortized query time per witness.
Proof 4.3**.**
We make use of Lemma 1 and its parameter . In particular, the total cost of solving Convolution3SUM is at most expected time, where is the time needed to preprocess an -sparse instance of a convolution witness and is the time per witness query for an -sparse instance of a convolution witness.
If we choose we have that for and we solve Convolution3SUM in time which is truly subquadratic.
5 From Reporting to Decision I: Hardness of Partial Convolutions
We further consider the problem of reporting witnesses for convolutions. However, now we use the third step of our framework. We will construct a search data structure over decision problems which will allow us to efficiently search for witnesses. This will be our method for proving CLBs for the decision problems of partial convolutions [22]. Specifically, we intend to generate a data structure that uses convolutions on small sub-vectors of the input vectors in order to solve the problem. However, the data structure cannot be fully constructed as it will be too large. Hence, the construction is partial and we defer some of the work to the query phase.
We start with Lemma 1, and focus on an -sparse instance of the convolution witnesses problem. We generate a specialized search tree for efficiently finding witnesses, which is created in an innovative way exploiting the sparsity of the input.
5.1 Search Tree Construction
Assume, without loss of generality, that is a power of . We construct a binary tree in the following way. First, we generate the root of the tree with the convolution of and . Then we split into sub-vectors, say and , each containing exactly s. For each sub-vector we generate nodes that are children of the root, where the first node contains the convolution of and and the second node contains the convolution of and . We continue this construction recursively so that at the th recursive level we partition into sub-vectors each containing s. A vertex at level represents the convolution of and a sub-vector containing s. The vertex has two children, one represents the convolution of and the sub-vector of with the first s of (denoted by ). The other represents the convolution of and the rest of with the other s (denoted by ). We stop the construction at the leaf level in which is split to sub-vectors that each one of them contains s from , for some to be determined later. Calculating the convolution in each vertex is done bottom-up. First, we calculate the convolution for each vertex in the leaf level. Then, we use these results to calculate the convolution of the next level upwards. Specifically, if we have vertex that represent the convolution and some sub-vector and it has two children one which represents the convolution of and and the other which represents the convolution of and , then for every , where and are the lengths of and respectively, and we consider the value of out of range entries as zero. This way we continue to calculate all the convolutions in the tree until reaching its root.
**Construction Time. ** It is straightforward to verify that the total cost of the construction procedure is dominated by the time of constructing the lowest level of the binary tree. In this level, we have sub-vectors of as each of them has 1’s and the total number of s in is . We calculate the convolution of with each of these sub-vectors, which can be done in time. Thus, the total time needed to build the tree is . Therefore, the total time for calculating the binary trees for all -sparse instances of the convolution witnesses problem is .
**Witness Search. ** To search for a witness we begin from the root of the binary tree and traverse down to a leaf containing a non-zero value in the result of the convolution at the query index (adjusting the index as needed while moving down the structure). The search for a leaf costs logarithmic time per query (as the tree has logarithmic height and in each level we just need to find a child with a non-zero value in the convolution it represents in the specific index of interest). Within the leaf, representing the convolution of and some sub-vector of we can simply find a witness in time as contains just s. Thus, as we have false-positives over all instances, the total time for finding all them is .
Consequently, using the binary tree for solving Convolution3SUM will cost time, which for is time. Since the tradeoff between the preprocessing time and query time meets at , any improvement to the running time of either of them will imply a subquadratic solution for the Convolution3SUM problem.
5.2 Conditional Lower Bounds for Partial Convolution
As a consequence of our discussion above we obtain the following results regarding partial convolution and its indexing variant:
Theorem 5.1**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial convolution problem with time, even if and the number of ones in both input vectors are less than .
Proof 5.2**.**
We make use of Lemma 1. In order to construct the binary tree as described in Section 5.3, we need to be able compute the convolution of with some sub-vector of for each leaf in the tree (all other convolution can be calculated efficiently from the convolutions in the leaves as described in the previous section). Recall that both input vectors have length , s (which is for , where is a positive constant), and we are interested in finding their convolution result only at the indices (that is, ). If we preprocess the input for partial convolution in truly sublinear time (for example, proportional to ) then the total time for constructing all the search trees will be while the total query time will remain . Choosing for small enough constant and setting , we obtain a subquadratic solution to Convolution3SUM.
Theorem 5.3**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial convolution indexing problem with preprocessing time and query time, even if both and the number of ones of the input vectors are .
Proof 5.4**.**
Use Lemma 1 and the previous discussion. If the preprocessing time for the partial convolution indexing problem is truly subquadratic and queries are answered in truly sublinear time then the total time for constructing all the structures for all instances is while the total time for all of the queries remains (note that ). Choosing for small enough constant and setting , we obtain a subquadratic algorithm for Convolution3SUM.
5.3 Search Tree Construction
Notice that the convolution of and immediately provides the number of witnesses for each index in linear time (since the vectors are binary).
Assume, without loss of generality, that is a power of . Let be a power of 2 to be determined later. For every we split the two input vectors to sub-vectors of size , and for each pair of sub-vectors, one from and one from , we compute their convolution. We construct a quad-tree such that each vertex contains the convolution between two sub-vectors. Each vertex (besides the leaves) has exactly 4 children, defined in the following way. If corresponds to the convolution between two sub-vectors and of length , then its children correspond to the convolutions between the sub-vectors of length that are the halves of the sub-vectors and .
Formally, the convolution vector is defined to be . This is defined for all . Consider a vertex that represents sub-vectors and of length , where and , i.e. . Then, and (for ). Hence, restricted to and is
. For most and the value is out of scope, that is . It is easy to verify that summing over the sub-vectors of size that are in scope for , . Hence, if there is a witness for then we find it by finding a witness for where is non-zero.
**Construction Time. ** Every leaf in the quad-tree represents a pair where . Since the constructed tree is a complete quad-tree, it is straightforward to verify that the total cost of the construction procedure is dominated by the time of constructing the lowest level of the quad-tree. In this level, the length of the convoluted sub-vectors is . Thus, the total time needed to build the tree is since we compute the convolution between every pair of sub-vectors (one from and one from ) of length (we have pairs), and each such convolution costs time. Thus, the total time for calculating the quad trees for all instances of the -sparse convolution witnesses problem is .
**Witness Search. ** To search for a witness we begin from the root of the quad-tree and traverse down to a leaf containing a non-zero value in the result of the convolution at the query index (adjusting the index as needed while moving down the structure). The search for a leaf costs logarithmic time per query (as the tree has logarithmic height and in each level we just need to find a child with non-zero value in the convolution it represents in the specific index of interest). Within the leaf, representing a pair of sub-vectors and , we compute all witnesses of in time. Thus, the total time for finding all the false-positives is .
Consequently, using the quad-tree for solving Convolution3SUM will cost time. If we choose we balance the two and obtain which is time, which is too high for obtaining a lower bound from the 3SUM conjecture. However, we now refine this idea.
**Improved Construction. ** In order to obtain a better total running time we use a different construction as follows. For every we only split into sub-vectors of size , and compute the convolution between and each sub-vector of . Hence, instead of a quad-tree we obtain a binary tree. In this tree, each vertex corresponds to the convolution of and a sub-vector of of length and has as its children the 2 vertices corresponding to convolutions between and the sub-vectors of length that are the halves of . Specifically, as before we define . Moreover, restricted to (and all of ) is .
The total cost of building this tree is time. The search for a leaf costs logarithmic time per query. Searching within the leaf will still cost time in order to find all witnesses for a specific index of the convolution it represents by using the naive algorithm. This still requires running time as before, even for the best choice of . However, this is a step toward the next refinement that gives us the desired improvement.
**Even Further Improvement. ** We further reduce the search time by splitting the vector into (unequal sized) sub-vectors of during the construction phase according to the location of the 1s in as opposed to sub-vector lengths. Recall that there are ’s in . For the sake of clarity, assume that there are exactly ’s in . First we generate the root of the binary tree with the convolution of and . Then we split into sub-vectors, say and , each containing exactly ’s. For each sub-vector we generate nodes that are children of the root, where the first node contains the convolution of and and the second node contains the convolution of and . We continue this construction recursively so that at the ’th recursive level we partition into sub-vectors each containing ’s. A vertex at level represents the convolution of and a sub-vector containing ’s. The vertex has two children, one which represents the convolution of and the sub-vector of with the first ’s of and the other which represents the convolution of and the rest of with the other ’s.
The leaf level contains sub-vectors with ’s from . Hence, the computation of all witnesses of only requires access to at most ’s for which , thereby taking time. Thus, the total time cost of this refined solution is which for is time. Since the tradeoff between the preprocessing time and query time meets at , any improvement to the running time of either of them will imply a subquadratic solution for the Convolution3SUM problem.
6 From Reporting to Decision II: Hardness of Partial Matrix Multiplication
Using ideas of the same flavor as those from Section 5 we prove CLBs on the partial matrix multiplication problem, which is defined in the introduction.
We start with Lemma 1 which shows how to reduce an instance of Convolution3SUM to instances of convolution witnesses problem. We will prove the CLB by showing that partial matrix multiplication can be used to solve a major component of the computation necessary. We focus, again, on two binary vectors and of size (out of the pairs of vectors), each containing s, and their convolution result . Similar to Section 5, we construct a search tree to seek for witnesses. However, this time we partition each of the vectors and into sub-vectors, and the partitioning method here slightly differs from the one in Section 5. The main obstacle is to guarantee the spareness of the input and the required output of the matrices we will use in our construction.
The tree we construct for efficiently searching for witnesses is computed as follows.
**Quad Tree Construction with Special Leaves ** First partition each vector to sub-vectors with each sub-vector containing s. Then, partition each sub-vector whose length is more than into smaller sub-vectors with length exactly except the last one that might be shorter. Pad each sub-vector with [math]s, if necessary, so that all lengths are exactly . Denote the sub-vectors . It is straightforward to observe that:
Observation 1**.**
. That is, .
Hence, the partition of is to (padded) sub-vectors , each of length and with s each. The same process is done for vector and we get sub-vectors that satisfy the same properties. We assume without loss of generality that and that is a power of two.
We construct a quad tree instead of the binary tree from Section 5.3. For integers denote by the sub-vector of that is the concatenation of the sub-vectors . Similarly, for integers denote by the sub-vector of that is the concatenation of the sub-vectors . The root of the quad tree will contain the result of the convolution (which we compute later) of and , which are and . The root has four children which correspond to all the convolutions between the 4 pairs of sub-vectors in . Recursively, a vertex representing the convolution of a pair and has 4 children representing the convolutions of the 4 sub-vector pairs in .
Our goal is to compute for each vertex in this tree the convolution of the two sub-vectors that it covers. In Section 5 we directly computed the convolution for every node. Here, we will use matrix multiplication in order to achieve our reduction. We do the computation on the leaves of the tree (we shortly explain how) and then use a bottom-up traversal of the tree where we compute the convolution for an inner vertex from the convolutions of its children (without computing it directly).
**Seeking a Witness ** This is literally done in the same way as described in Section 5.3. When we are looking for a witness for a query number we traverse down the tree in logarithmic time, until we reach a leaf with at most 1s. A naive algorithm at the sub-vectors of a leaf will complete the process. Thus the total query time is .
**Partial Convolution via Partial Matrix Multiplications ** We make use of matrix multiplication in order to efficiently compute the convolutions at the leaves as follows.
We construct a set of matrices , two for each as follows. The first row in matrix is the sub-vector . The th row of is the sub-vector shifted right by , i.e. discard the least significant bits and add [math]s to be the new most significant bits. Each such matrix is called a shift right matrix. In a similar manner, the first row in matrix is the sub-vector . The th row of is the sub-vector shifted left by , i.e. discard the most significant bits and add [math]s to be the new least significant bits. Each such matrix is called a shift left matrix
Now, construct a matrix from the sub-vectors of such that the th column of is . This matrix has rows and columns. We partition into squared matrices each having exactly rows and columns.
The matrix multiplication of and together with the matrix multiplication of and computes all the shifts of with the sub-vectors represented by . In other words, we are computing the convolution of leaves with two matrix multiplication of two matrices of size . Hence, the overall time to compute the convolutions of the leaves will be where is the time needed for multiplying two squared matrices of size . The computation of the convolution of inner vertices can be computed from the convolution of its children. It is straightforward to see that the time of the computations of the convolutions is dominated by the computation of the convolutions in the leaves.
6.1 Hardness of Partial Matrix Multiplication
We are now ready to prove the following CLBs on partial matrix multiplication and its indexing variant.
Theorem 6.1**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial matrix multiplication problem running in expected time, even if and the number of ones in the input matrices is .
Proof 6.2**.**
Consider the reduction from Lemma 1. Finding witnesses from the instances of witnesses convolution problem can be done by using the tree we have just constructed and seeking witnesses within it. Recall that for each instance of the witnesses convolution problem we only look for witnesses for locations in (that corresponds to the indices in the bucket it represents, see details in Lemma 1).
As explained in the previous subsection, the total time to construct the quad tree is where is the time needed for multiplying two squared matrices of size . The results of the matrix multiplications of some and all the matrices in correspond to the convolution of sub-vectors of with . However, as noted before, we are interested in computing the result of each convolution only at locations (that correspond to the indices specified by elements of bucket ). Therefore, after partitioning and creating the matrices in which are of size the number of locations in the result of the multiplication of some with some matrix in that we are interested in is in expectation. But we will require the worst-case number of locations to be at most , so for each result that has more than locations which we are interested in we will split the computation into several iterations, each time considering a set of different locations. Since the total number of locations over all the results is no more than , this only imposes a constant factor time overhead.
Now, in the construction time of the quad tree, instead of the time for multiplying two squared matrices of size we just require the time to compute their multiplication in some specific locations. Moreover, the number of s in any is which is also the number of s in any matrix in . If the time for computing the multiplication of these sparse matrices at the specified locations is then the total construction time will be . Therefore, the total time for constructing all the trees for all instances will be , and the query time is . Choosing for some small constant and we obtain a truly subquadratic solution for 3SUM.
Theorem 6.3**.**
Assume the 3SUM conjecture is true. Then there is no algorithm for the partial matrix multiplication indexing problem with preprocessing time and query time.
Proof 6.4**.**
We make use of Lemma 1 and our quad tree. This time, we preprocess with a collection . Each set corresponds to the indices of interest in the result of the multiplication of and some matrix in (see the details in the proof of the previous theorem). After the preprocessing phase we answer queries to compute the partial multiplication of with matrices in using the indices from sets in . The construction time of the quad tree is , where is the preprocessing time of partial matrix multiplication indexing for sparse matrices of size while , and is the corresponding query time. Therefore, if there is an algorithm for the partial matrix multiplication indexing problem with preprocessing time and query time, then the total construction time for all trees is , and the total time spent on all queries is . Choosing for some small constant and we obtain a truly subquadratic solution to 3SUM.
Notice that Theorems 6.1 and 6.3 hold even when considering the simple case of boolean matrix multiplication.
7 Hardness of Data Structures for Histogram Indexing
In order to prove a CLB for both the histogram indexing problem and the histogram (indexing) reporting problem, we will first focus on reducing 3SUM to the histogram reporting problem, and then turn our focus to reducing the the histogram reporting problem to the histogram indexing problem.
7.1 Reducing Convolution3SUM to Histogram Reporting
We are given an ordered set of integers for which we want to solve DiffConv3SUM. Our methodology here is to encode the input integers into a compact string so that histogram indexing with carefully chosen query patterns implies a solution to DiffConv3SUM. Since the size of the universe of the input integers can be as large as , we hash down the universe size while (almost) maintaining the linearity property of the input. To do this, we make use of an almost-linear almost-balanced hash function as defined in Section 3, and apply to all of the input integers.
After utilizing to compress the input range, we are ready to encode the input and create the string . To do this, we encode each separately, and then concatenate the encodings in the same order as their corresponding original integers in . We use the following encoding scheme, using an alphabet . Some other encoding schemes, which surprisingly provide the same bounds, are discussed in Appendix B.
Encoding 1. The encoding will consist of two separate partial encodings concatenated together. The first partial encoding is partitioned into parts which together will represent in base . For the th part of this first partial encoding is a unary representation of using , and is denoted by . The first partial encoding of , which we also call a regular encoding of , is
.
For the second partial encoding we encode the complement of each which is the unary representation of using , and is denoted by . The second partial encoding of , which we also call a complement encoding of , is
. The full encoding of is the concatenation of and which we denote by . Finally, the string is set to be
. The size of is clearly . We denote the substring of starting at the location of the beginning of and ending at the location of the end of by .
Consider a Parikh vector obtained from and where the th element has a count of . We say that represents . For a vector we define . We also define the carry set of to be . It is easy to see that and that can be obtained from in time. We call the base of . We have the following lemma regarding :
Lemma 2**.**
If there exists a pair such that and , then the Parikh vector of must be in .
Proof 7.1**.**
Since is linear we know that . This is equivalent to saying that . In we have the full encoding of all integers . There are exactly integers between and . Therefore, each of them adds occurrences of each () to . In addition to the full encodings of these integers we have two more partial encodings: and . Notice that and represent and , respectively, in base . If we look at the vector (the base of ) after subtracting from the count of each character, we obtain the representation of in base , which intuitively implies that is the Parikh vector that we are looking for. However, it is possible to generate a carry at each of the digits of the base during the addition of . To handle these carries we consider all possible carry scenarios and generate a vector for each of the scenarios. These carry scenarios are exactly represented by the vectors in , as each vector in the definition of specifies the indices in which we have a carry. Hence, the Parikh vector of must be one of the vectors in .
Thus, we preprocess with an algorithm for histogram reporting, and then query the resulting data structure with all the vectors in , whose base represents some , in an attempt to decide if is part of a solution to DiffConv3SUM. The reported locations are classified into two types:
Candidates: Locations where the histogram match begins and ends exactly between the complement and regular encodings of two input integers. All these locations correspond to and such that for the particular for which the query was constructed, we have and also .
Encoding Errors: All matches that are not candidates.
While encoding errors clearly do not provide a solution for DiffConv3SUM on , candidates may also not be suitable for a solution since the function introduces false-positives. The following lemma bounds the total expected number of false-positives (both from false-positive candidates and encoding errors) that can be reported by a single query vector (and the vectors in the carry set that it serves as it base). Its proof appears in the appendix.
Lemma 3**.**
The expected number of false positives that are reported when considering all vectors in (whose base represents ) as queries is .
Proof 7.2**.**
We focus on that is queried when considering . This vector implies the value of which is the length of substrings of that can have as their Parikh vector. Clearly, there are at most such substrings. We focus on the substring from location to location in . Due to our encoding scheme, this substring contains a (possibly empty) suffix of , for some , followed by full encodings of some integers from , and then a (possibly empty) prefix of , for some integers and . The only way in which we may falsely report location as a match is if for each the number of characters in the substring of , denoted by , is equal to the count of in , denoted by . For a given , since the substring contains complete encodings, we can consider which is a function of , compared to . Now, since is uniformly random (due to ) in the range , the probability that they are equal is . This is true for every character on its own, but when considering all of the characters, once we set the count for the first characters the count for the last character completely depends on the other counts. Therefore, the probability that the comparison passes for all of the characters only depends on the first characters, and is . By linearity of expectation over all possible locations in and all vectors in , the expected number of false positives is .
7.2 Hardness of Histogram Reporting
Utilizing the reduction we have described in the previous section, that transforms an ordered set to a string , we can prove the following CLB.
Theorem 7.3**.**
Assume the 3SUM conjecture holds. The histogram reporting problem for an -length string and constant alphabet size cannot be solved using preprocessing time, query time and reporting time per item, for any .
Proof 7.4**.**
We follow the reduction in Section 7.1. For an instance of the histogram reporting problem on a string of length denote the preprocessing time by , the query time by and the reporting time per item by . The total expected running time used by our reduction to solve DiffConv3SUM is , where is the expected total number of false positives. This running time must be , unless 3SUM conjecture is false.
Since and , then either , , or . Set to be . By straightforward calculations following our choice of we get that , , and .
7.3 From Reporting to Decision: Hardness of Histogram Indexing
We make use of Theorem 7.3 to obtain a CLB on the decision variant of the problem. Amir et al. [5] proved similar lower bounds based on a stronger 3SUM conjecture. Our proof here shows that this stronger assumption is not needed and that the common 3SUM conjecture suffices. The idea of the proof is to make the expected number of false-positives small by a suitable choice of .
Lemma 4**.**
Assume the 3SUM conjecture holds. The histogram indexing problem for a string of length and constant alphabet size cannot be solved with preprocessing time and query time.
Proof 7.5**.**
We follow the reduction in Section 7.1. In order to use histogram indexing we will reduce the probability of a false positive for any query to be less than . From Lemma 3 we know that the expected number of false positives due to query is at most . By setting to be for sufficiently large constant the number of false positives is strictly smaller than , which implies immediately that the probability of a false positive is strictly smaller than . Therefore, if we were to solve histogram indexing instead of histogram reporting on the same input as in Theorem 7.3, the probability of a false positive is less than . We can make this probability smaller by repeating the process times, each time using a different hash function . This way, the probability that all of the queries that are due to a specific return false positives is less than . If a given passes all of the query processes (that is, a positive answer is received by each one of them), then we can verify that there is indeed a match with this in time, which will add a negligible cost to the expected running time in the case it is indeed a false positive. Thus, the total expected running time of this procedure is , where is the preprocessing time (for input string of length and alphabet size ) and is the query time (for the same parameters). Therefore, unless the 3SUM conjecture is false, there is no solution for histogram indexing such that and . If we plug-in the value of we have chosen and follow the calculations in the proof of Theorem 7.3 (with ), then we obtain that there is no solution for the histogram indexing problem with and .
We generalize this CLB by presenting a full-tradeoff between preprocessing and query time. The idea of the proof is to artificially split the encoded string to smaller parts, so we can have many false positives in , but the probability for a false positive in each part will be small.
Theorem 7.6**.**
Assume the 3SUM conjecture holds. The histogram indexing problem for a string of length and constant alphabet size cannot be solved with preprocessing time and query time, for any .
Proof 7.7**.**
The idea to get a full-tradeoff between preprocessing time and query time is to artificially split the encoded string to smaller parts, so we can have many false positives in but the probability for a false positive in each part will be small. We achieve this artificial split by using special character as a separator and construct a search data structure for queries in the following way.
Search Structure Construction. Say we have encoded using encoding 1 with characters and formed a string . Let be a query Parikh vector such that the sum of all counts in it is . That is, can be the Parikh vector of a substring of that has length . We add special characters to for some . The special characters are added to at positions for . We denote the resulting string by .
*Denote by the count of character in the Parikh vector . We generate vectors from our query vector . These vectors are given by the set
. Querying with a vector such that can find a substring of with matching Parikh vector only if this substring in (without the special characters ) begins at location . This is because of the limitations posed by the special character .*
To handle query vectors whose sum of counts is in the interval , we will add more special characters to . Specifically, we add 1 special character at positions for , 2 special characters at positions for , and 3 special characters at positions for . Again, we denote the resulting string . With the special characters in , we can handle a query Parikh vector that the sum of its counts is in the following way. We first extend to contain a count for and initialize it to the number of occurrences of in the substring (the substring of that starts at location [math] and ends at location ). We call this vector . We create sequence of query vectors such that is created from by adding to . It is straightforward to observe that each query vector can match at most locations in . That is, by adding just special symbols to we artificially split the string to parts.
Multi-level Construction.* We explain how to handle a query Parikh vector
that the sum of all counts in it is . To do this, we create a structure with levels, such that each one of them is created by cutting and adding special characters. Level 0 will be the string we constructed previously. For level , we cut the string to parts of (almost) equal length by cutting at positions of for . We adjust the cutting so that each part will end at the end of a full encoding of some number . We denote the resulting parts by . Moreover, we also cut at positions for . Again, we adjust the cutting so that each part will end at the end of a full encoding of some number in . We denote the resulting parts except the first and last one by . Observe that , the length of each part in is , and the total length of all parts is . We stop the process at level in which we have parts in . We add to each part special characters . We place them similarly to how we have done it in level 0. Specifically, we add 1 special character at positions for , 2 special characters at positions for , and 3 special characters at positions for . After creating all these levels and parts we preprocess each of these parts as an instance of histogram indexing. Then, given a a query Parikh vector that the sum of its counts is , we first find the right level to handle it. This is the level for which we have . if we use level 0 and if we use the last level. Let the right level be level . We first extend to contain a count for and initialize it to the number of occurrences of in the substring (for some and ). We call this vector . We create a sequence of query vectors such that is created from by adding to . We now query each part in with each vector from the set of vectors we have created. It is straightforward to observe that we have queries in total and each query can match at most locations of some part in .*
Time analysis. Now, we analyse the preprocessing time and query time of our construction. Say we use encoding 1 to create . The expected number of false-positives for a query without the special character is (see Lemma 3). In Lemma 4 we required that this number will be strictly less than 1/2 in order to guarantee that with high probability we have no false positives for a given query (after amplification). Following our construction, we have queries (which is smaller than for some constant ) for each query vector , so that each of these queries covers only some of the substrings of . Therefore, we can allow the number of false positives per vector to be strictly less than , which will be strictly less than 1/2 for each of the queries corresponding to . We can reduce the probability for a false positive per query by creating copies of our structure, each time using a different hash function . Then, for every query vector we query all structures. This way, the probability that all of the queries return a false positive is less than . This is due to the fact that using different does not change the order of the encoded numbers in the string . It only changes their encoding. Therefore, a query vector can match the exact same locations in all structures.
That being said, we only need to ensure that . This is satisfied if we choose for some sufficiently large constant . By this choice of we get that . Our structure has levels. The total length of the string parts in each level is . Moreover, in each level we allow false positives in total. Therefore, the construction time is dominated by the preprocessing time of level 0, as all levels have the same length and the preprocessing time is for some . We construct copies of our structure, so the overall preprocessing time is which is the preprocessing time for histogram indexing on input string of length and alphabet size . We have numbers in and for each number in we have queries (vectors in ). These are the queries we have in the analysis in proof of Lemma 4. Using our special character we have created query vectors for each of these queries. Therefore, the total number of query vectors is ,therefore, . Let be the query time for histogram indexing on input string of length and alphabet size . The total expected running time of our method for solving 3SUM is for constant alphabet size . Therefore, unless the 3SUM conjecture is false, there is no solution for histogram indexing such that and . If we plug-in the value of we have chosen, then we obtain that there is no solution for the histogram indexing problem with and .
Improving the tradeoff.* We get full tradeoff between preprocessing time and query time for each alphabet size . We wish that this tradeoff will contain the points given by Lemma 4 when gets close to zero. However, we have "wasted" one character for . We can bypass this problem by encoding using encoding 3 (see Appendix B). In this encoding we have a special character that separates between partial encodings. We can use this character also as . In order to do so, we need to ensure that there will be no confusion between the two uses of . We call the characters used for separating between partial encodings separating characters and the characters used as splitting characters. For a query vector we have , where is the number of separating characters counted by and is the number of splitting characters counted by . Recall that in our construction each part of in each level has regions with 1, 2 or 3 special characters . Instead of this amount of special characters, we place , or special characters for some constant . Now, for each query vector we create the query vectors by adding each time to the count of (that represents ). For a query vector the count of all the characters except implies the number of full encoding we have. Let be a query vector for then the number of full encodings will be . Therefore, if matches a substring of some part of , the separating characters in this substring must be at least . Out of the only two separating characters that can be mistakenly considered as splitting characters are those between the partial encodings of some and such that . However, as splitting characters come in groups of characters for , we cannot mistakenly exchange two separating characters for a complete group of splitting characters. Therefore, the only possibility for a confusion between the two types is by matching a substring that contains a partial group of splitting characters. This can happen only at the suffix or prefix of the substring. Nevertheless, we can prevent this possibility by adjusting the placement of the splitting characters to the end of the full encoding in which they occur. That is, if a group of splitting characters occurs inside the full encoding of some we move them to the end of its encoding in .*
Consequently, by the use of as both separating and splitting character we can get the same splitting effect without the need for an additional character. If we redo the running time calculations, but this time with encoded using characters, we get that unless the 3SUM conjecture is false, there is no solution for histogram indexing such that and .
For encoding 3 we need at least 4 characters in the alphabet (at least two characters for encoding a number, one for padding and another to separate between partial encodings) to extend the result to we use encoding 2 (see Appendix B). In this encoding we have as a padding character. Specifically, for each number we add times as padding. We can use not just for padding, but also as our special character . Consequently, by choosing and following the same analysis as before we prove that the same CLB holds also for alphabet of size (note that the number of characters we have added only increase the size of the string by some constant factor).
Appendix
Appendix A Appendix: Summary of Applications
Appendix B Appendix: Other Encodings for Histogram Indexing
We describe two additional encodings of an instance of DiffConv3SUM to a string, which then can be used to solve the instance using histogram reporting and histogram indexing. Surprisingly, although these encodings have somewhat different flavour they all give the same CLBs as encoding 1 given in Section 7.1.
Encoding 2. The idea behind this encoding is to use encoding 1 on alphabet of size (instead of ), and then use the additional character as a padding tool so that the lengths of the partial encodings of each integer will be exactly . For each we first create both and as defined in encoding 1. We denote by the length of some encoding . We first encode by . Then, we encode it by . Finally, the full encoding, denoted by , is the concatenation of the two encodings.
Using this encoding we create a string by concatenating for all . We also construct query pattern for each , which is a Parikh vector such that the th element of this vector is for . For the value of the th element will be . We can also define a carry set in an analog way to the carry set defined in Section 7.1. This set contains all vectors obtained from in time in order to handle carry issues. It can be shown in a similar manner to Lemma 2 that if there exist a pair such that and , then had some as its Parikh vector.
Regarding the length of the encoded string and the expected number of false-positives induced by the reduction we have the following lemma:
Lemma 5**.**
The string created by the reduction from DiffConv3SUM to histogram reporting using encoding 2 is of size . The number of expected false positives when considering a query vector is .
Proof B.1**.**
Each is embedded by the hash function to a number in . Then, it is divided to parts (that represent in base ) each of them encoded by unary encoding. Therefore, each of the encoded parts is of size at most , while the last letter of the alphabet used for padding completes it exactly to . The same calculation is true to both and . That being said, the total length of the string using encoding 2 is .
Now, we consider the expected number of false positives for some query vector . In a similar manner to what we have shown for encoding 1 (see Lemma 3), we are interested in the probability , where ( represents the number of occurrences of in a substring of of length starting at location . represents the same number without taking into account the occurrences of in the fully encoded integers in that substring). The properties of the (almost) linear hash function guarantee that the value of is expected to be uniformly distributed in its range. Therefore, we have . We conclude that as the number of occurrences of all letters (except the one used for padding) is (almost) independently and uniformly distributed. By this, we have that the expected number of false-positives for a query vector is .
We can plug and the expected number of false-positives, which we have calculated in the previous lemma, in the proof of Theorem 7.3. Choosing and finally substituting we obtain the same CLBs that appear in Theorem 7.3. Moreover, the same CLBs as in Lemma 4 can be achieved using this encoding, if we choose to be for sufficiently large constant so the expected number of false positives we have is strictly less than .
Encoding 3. In this encoding we first create the same string as in encoding 2 using characters (instead of , and then add special characters to the string. We use as the special character (note that this time was not used by encoding 2, as it make use only of the first characters in the alphabet). We add at every position in the string for . That is, we use to mark the border of the partial encodings of each number in the string created by encoding 2.
We construct a query for each , which is a Parikh vector such that the th () element of this vector is . For the value of the th element will be . Finally, for the value of the th element will be . We can also define a carry set in an analog way to the carry set defined in Section 7.1. This set contains all vectors obtained from in time for handling carry issues. As before, It can be shown that if there exist a pair such that and , then had some as its Parikh vector.
Regarding the length of the encoded string and the expected number of false-positives induced by the reduction we have the following lemma:
Lemma 6**.**
The string created by the reduction from DiffConv3SUM to histogram reporting using encoding 3 is of size . The number of expected false positives when considering a query vector is .
Proof B.2**.**
Each is embedded by the hash function to a number in . Then, it is divided to parts (that represent in base ) each of them encoded by unary encoding. Therefore, each of the encoded parts is of size at most , while , that is used for padding, completes each of them exactly to . The character occurs only times. That being said, the total length of the string using encoding 3 is of size .
Now, we consider the expected number of false positives for some query vector . The use of the padding character and the special character guarantees that every reported match starts exactly between and and ends exactly between and for some and such that . Therefore, no false-positives are created by encodings errors. That being said, the expected number of false-positives for a query vector is exactly the number of false-positives introduced by the use of the hash function which is .
We can plug and the expected number of false-positives, which we have calculated in the previous lemma, in the proof of Theorem 7.3. Choosing and finally substituting we obtain the same CLBs that appear in Theorem 7.3. Moreover, the same CLBs as in Lemma 4 can be achieved using this encoding, if we choose to be for sufficiently large constant so the expected number of false positives we have is strictly less than .
We note that the encoding 2 requires one extra padding character and encoding 3 requires another special character, so for them Theorem 7.3 and Lemma 4 hold from slightly larger .
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] Amir Abboud and Kevin Lewi. Exact weight subgraphs and the k-sum conjecture. In International Colloquium on Automata, Languages and Programming, ICALP 2013 , pages 1–12, 2013.
- 2[2] Amir Abboud and Virginia Vassilevska Williams. Popular conjectures imply strong lower bounds for dynamic problems. In Foundations of Computer Science, FOCS 2014 , pages 434–443, 2014.
- 3[3] Amir Abboud, Virginia Vassilevska Williams, and Oren Weimann. Consequences of faster alignment of sequences. In International Colloquium on Automata, Languages and Programming, ICALP 2014 , pages 39–51, 2014.
- 4[4] Amir Abboud, Virginia Vassilevska Williams, and Huacheng Yu. Matching triangles and basing hardness on an extremely popular conjecture. In Symposium on Theory of Computing, STOC 2015 , pages 41–50, 2015.
- 5[5] Amihood Amir, Timothy M. Chan, Moshe Lewenstein, and Noa Lewenstein. On hardness of jumbled indexing. In International Colloquium on Automata, Languages and Programming, ICALP 2014 , pages 114–125, 2014.
- 6[6] Ilya Baran, Erik D. Demaine, and Mihai Patrascu. Subquadratic algorithms for 3SUM. In Workshop on Algorithms and Data Structures, WADS 2005 , pages 409–421, 2005.
- 7[7] David Bremner, Timothy M. Chan, Erik D. Demaine, Jeff Erickson, Ferran Hurtado, John Iacono, Stefan Langerman, Mihai Patrascu, and Perouz Taslakian. Necklaces, convolutions, and X+Y. Algorithmica , 69(2):294–314, 2014.
- 8[8] Peter Burcsi, Ferdinando Cicalese, Gabriele Fici, and Zsuzsanna Lipták. Algorithms for jumbled pattern matching in strings. Int. J. Found. Comput. Sci. , 23(2):357–374, 2012.
