Incremental FPT Delay
Round 1
Reviewer 1 Report
Overall this article gives a nice contribution to the field and will,
I think, be of interest to the community.
The English language is sometimes a bit strained and a thorough proof
reading is recommended.
Specific comments (numbers refer to the line numbering in the
manuscript):
19. "is not centrally focused" This is an awkward formulation
29. "which rather is a common" -> "which is a rather common"
48-49. This sentence is also awkward
52. "is widely not seen as a correspondent of NP on the classical..."
Awkward, please reformulate
83-84. "there exists a work" Reformulate. Also, for all other
citations in this paragraph, you give the names of the authors (or at
least the first author.
133-136. Is this really relevant here?
190. "if for all x in Q AND ALL i"
220. "these previously introduced notions" -> these notions
252. "the question on" -> "the question of"
226. remove "besides"
254-255. "the restriction to finite solution sets" I don't understand this.
Definition 3, item 2, says that the solution set must always be
finite. Please explain.
276-277. This sentence is hard to understand. Please reformulate.
Between 283 and 284. It is a bit unfortunate that you name the
priority queue Q, since that letter is already used for the set of
instances.
312. You haven't yet introduced the A(x,y) notation
325. "balanced problem" In the previous definition you write "balanced
relation". Why the difference?
338. What is the role of a and b? Please explain why they are needed.
341. "doe" -> "do"
392. What is A(x) here?
415. "Def 6" I think this should be Def 7
422. FPT -> F(FTP)
Author Response
Please see attachment.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
The main content of this paper involves translating a number of facts about the relationship between different enumeration complexity classes from the classical setting to that of parameterized complexity; there is also one result (Theorem 4) which establishes an (easy) connection between the equivalence of certain pairs of complexity classes and that of their parameterized counterparts.
None of the results involves any new methodological insights; the majority are obtained by making trivial changes to the argument used to prove the classical analogue, although this is not always made clear in the text. I also think there is a small error in one of the proofs (Theorem 3, see below) although this should be straightforward to fix. Overall, although it is worthwile for the community to have these results stated in the parameterized setting, I am not convinced that there is enough scientific content here to merit publication as a standalone paper. I would encourage the author to consider is reforulating the paper primarily as a survey, which provides a detailed exposition on the corresponding results in the classical setting in addition to explaining how they can be extended to the parameterized setting; for this, the presentation must be substantially improved and a lot more background should be included (in general, in the current manuscript, rather too much familiarity with the proof techniques used in the existing literature is assumed). The quality of English also needs to be improved throughout.
DETAILED COMMENTS
Line 7: TF(para-NP) and F(FPT) shouldn't be used in the abstract without definition
Line 41-2: To provide context for your results, you need to provide a lot more detail on what was done by Capelli and Strozecki
Line 48-9: You should emphasise that the parameter is independent of the input size (otherwise we are allowed arbitrary dependence on the input size)
Line 53-5: Given the theme of the paper -- drawing connections between classical and parameterized complexity -- you should mention connections between the W-hierarchy and classical assumptions here (e.g. the relationship to ETH)
Line 68: "it seemed that" -- please be more precise; is this known subject to some hypothesis?
Line 71-3: "similar phenomena" -- please expand on what is meant here
Line 86-7: There is a large body of literature on parameterized counting complexity (probably more than on parameterized enumeration), so referencing only a masters thesis here does not seem adequate
Line 88-110: After reading the "Contribution" section it is still not very clear what results are contained in the paper; please fix this.
Line 114-118: You refer to many classes which you have not yet defined.
Line 162-3: It's not really true that "the runtime of enumeration algorithms is usually abandoned" -- consider OutputP
Line 171: You make a number of assumptions on your enumeration problems; I feel therefore that problems satisfying this definition need a more informative name than just "Enumeration problems"
Line 216-7: It would be easy to provide a brief intuition as to why Proposition 2 is true (the idea that we can wait to output previously computed solutions)
Line 264: Something seems to be missing at the start of Definition 8
Line 276: "the exponential sized priority queue" -- this needs explaining; you are assuming the reader is very familiar with the proof details from [12] which is not reasonable. You should explain the use of the priority queue before making this statement.
Line 282: The argument you use is essentially identical to the proof for the classical case. You should make this clear in the text, and emphasize any changes you have to make to the approach for the parameterized setting.
Line 283+4: Please explain the role of s in these calculations -- it is not clear to me where it is used
Line 298: "contrasts with" -- is this really what you mean?
Line 299: Requiring a specific order on the solutions is a strong additional requirement, which means this work provides less compelling evidence
Line 346: Please define what is meant by self-reducible in this context (the term is used slightly differently in different settings)
Line 373-377: This proof needs more detail; please expand.
Lines 400 and 423: "in fpt-time" -- the meaning of this is somewhat unclear in both places. You need to specify with respect to what input and what parameterization the time bound is fpt, as several different inputs are being considered in the proof.
Lines 400-404: Something seems to be missing here: there should be some allowance for the g(k(x)) factor in the time to check solutions (I suspect you need to change the requirement |w| \leq p(|x|) to take this into account)
Line 422: FPT -> F(FPT)
Line 461: Please give at least an informal definition of one-way functions
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Reviewer 3 Report
### Evaluation
The submitted manuscript presents complexity theoretical results in the intersection of enumeration and parameterized algorithms---an active subfield of parameterized complexity in past few years.
Somewhat naturally the presented results are quite technical and require many definitions that are not easy to follow, however, the author presents all of these in a structured way thus making this easier for the reader.
I find the new results sound (I have a minor issue with Theorem 2) and novel; well, the results follow the approach of Capelli and Strozecki but translate these into completely different setting which is a non-trivial task.
The paper is rather well-written; see my comments for typos and such I have spotted.
I believe it would be nice to have a broader view on parameterized enumeration in the introduction (see few pointers I am aware of below).
The only downside for me was the abstract---I was not really sure what is the contributions of the paper after reading it and, furthermore, was a bit puzzled by it.
In particular, the main result (as is nice mentioned e.g. in line97) should be given more precisely already here.
## Summary
All in all I like the manuscript and can (after some additional work) suggest it for acceptation.
### Suggestions for improvements
I believe that for parameterized conting/enumeration you should add more references.
For example check the recent work of Marc Roth or Radu Curticapean (I am adding just a few examples that I find relevant here):
- Marc Roth, Philip Wellnitz: Counting and Finding Homomorphisms is Universal for Parameterized Complexity Theory. SODA 2020: 2161-2180
- Radu Curticapean, Holger Dell, Marc Roth: Counting Edge-injective Homomorphisms and Matchings on Restricted Graph Classes. Theory Comput. Syst. 63(5): 987-1026 (2019)
- Marc Roth, Johannes Schmitt: Counting Induced Subgraphs: A Topological Approach to #W[1]-hardness. IPEC 2018: 24:1-24:14
Please check these and the references therein for more broader view on the related classes.
- l2,l3: subscript a
- l13: Papadimitriou, and Yannakakis -- add a comma
- l30: *enumeration of* structures for first-order
- l35: examples *of*
- l88: "Our Contribution"?
- l91: You cannot be certain that your research will lead to new investigations. I would propose to change "will be helpful" to "we hope will be helpful".
- l100: Here the reader does not know if $_a$ is just a weird part of name or a class-parameter (please mention it is the second).
- l130: the tuple $x,k$ should be from $Q \times \mathbb{N}$
- l140: please avoid nested O() notation
- l161: It would be nice to add also some monograph (if possible) for Emuneraion algorithms -- what about the one of Fomin&Kratsch?
- l212: space space
- l215: come *to* the opinion
- l216: more general *than* IncP
- l244: *an* FPT-enumeration
- l277: avoid it without *using the priority queue*.
- l283+2: Why is the first inequality strict?
- l283+4: add a comma before "where"
- l291: You mention that the proposed question is significant. I would thus propose to formulate a question/conjecture in an extra environment so that this question is more visible.
- Table1, last line, third column: g(\kappa'(x))
- l341: Why are the symbols 'a' and 'b' so important in the definition? It seems to make sense even without these artificial symbols. Are these symbols in \Sigma? From the definition of A and B they should, however, I think these are not anyhow ordinary symbols, are they?
- l343: I do not understand this sentence.
- l346: What does "these problems" refer to?
- l351: please add "\/" after "of"
- l364,l367: Please put the Prop~7(9) as a parameter of your cite command, i.e., \cite[Prop~7]{source}.
- l371: *Their arguments are* easily lifted...
- l374: this is inconsistent notation -- before you use '\subseteq' and now ''\subseteq'' (please change this everywhere)
- l373--l377: In this proof you define mappings whereas the definition requires to define a total relation. Please clarify this.
- l378: "For the subsequently lemma"
- l379: "classical result" -- if I am correct, then this result is from 2018/2019 -- is this really a classical result?
- l379: Does "It" refer to Lemma1? Please be more specific here.
- l388: *a* polynomial
- l390: *, then* -- add a comma
- l391: *, then* -- add a comma
- Proof of Theorem 3: You assume '#' is not in \Sigma -- please add this assumption.
- l416: *, there* -- add a comma
- l432: *, where* -- add a comma
- l457&l459: "If one does not consider space requirements" -- why is this not a part of Corollary 4?
Author Response
Please see the attachment.
Author Response File: Author Response.pdf
Round 2
Reviewer 2 Report
I thank the authors for addressing most of my previous comments so efficiently. However, I have one remaining concern relating to the proof of Theorem 3, which must be addressed in the final version.
You write:
"By construction, the trivial brute-force enumeration algorithm
checking all y#w is in time g(k(x))p(|x|) for every element of Sol(x). Accordingly, this gives para-ENUM-C \in OutputFPT as the runtime for OutputFPT algorithms encompasses |Sol(x)| as a factor."
This reasoning alone is not enough: to check every possible solution by brute force will take time g(k(x))p(|x|) for every *candidate solution* (i.e. every y#w with y \in \Sigma* and w \in {0,1}* with |w| \leq p(|x|)). On the other hand, as you say, OutpotFPT allows for the runtime to depend on |Sol(x)|, but in general the number of candidate solutions could be exponentially larger than |Sol(x)|, so checking each one in turn is not possible for OutputFPT (otherwise this would not be a very interesting class, since we could always achieve OutputFPT by brute force checking).
I believe this is exactly why you introduce the padding (otherwise this doesn't seem to be needed in the argument as written): the idea is that this blows up |Sol(x)| and indeed once we have determined that one y#w is a solution, we very easily know an exponential number of other solutions of the form y#w', which gives us some "free" time to check other candidate solutions. This is non-trivial, though, and seems to me to be the hardest and most important part of the argument, so must be explained in sufficient detail (in particular I would like to see a justification that the extra time we gain by having w \in {0,1}* is sufficient even if |\Sigma| is much larger than 2).
