Low rate is insufficient for local testability

  • Authors:
  • Eli Ben-Sasson;Michael Viderman

  • Affiliations:
  • Computer Science Department, Technion-Israel Institute of Technology, Haifa, Israel;Computer Science Department, Technion-Israel Institute of Technology, Haifa, Israel

  • Venue:
  • APPROX/RANDOM'10 Proceedings of the 13th international conference on Approximation, and 14 the International conference on Randomization, and combinatorial optimization: algorithms and techniques
  • Year:
  • 2010

Quantified Score

Hi-index 0.00

Visualization

Abstract

Three results are shown regarding locally testable and locally decodable linear codes. All three results rely on the observation that repetition codes have the same local testability and local decodability parameters as the unrepeated base code used to create them. The first two results deal with families of sparse linear codes, i.e., codes with dimension logarithmic in the code blocklength n. Such codes have been shown by Kaufman and Sudan [8] to be locally testable and decodable as long as all nonzero codewords have Hamming weight n ċ (1/2 ± n-Ω(1)). Our first result shows that certain sparse codes are neither locally testable, nor locally decodable. This refutes a conjecture of Kopparty and Saraf [9] which postulated that all sparse codes are locally testable. Our second result shows that the result of Kaufman and Sudan is surprisingly tight, and for any function h(n) = o(1) there exist families of sparse codes all of whose codewords have weight n ċ (1/2 ± n-h(n)) and these codes are neither locally testable, nor locally decodable. Our third and final result is about the redundancy of locally testable codes. Informally, the redundancy of a locally testable code is the minimal number of redundant tests sampled by a tester, where a test is said to be redundant if is a linear combination of other tests. Ben-Sasson et al. [1] introduced the notion of redundancy and showed that for every linear locally testable code the redundancy is at least linear in the dimension of the code. Our last result shows that redundancy is indeed a function of the code dimension, not blocklength, and that the bound given in [1] is nearly tight.