shorts/yesterday.tex

   1 %&pre
   2 \title{Yesterday, my program worked. Today, it does not. Why?}
   3 \date{2016{--}03{-}16}
   4 \begin{document}
   5 \maketitle
   6 \subsubsection*{Summary \& Evidence}
   7 %Summary (as briefly as you can - two or three sentences)
   8 The paper proposes an automatic method of narrowing down the lines of code
   9 responsible for a specific change in behaviour. Besides the method it also
  10 proposes extensions that allow handling of interfering fault-inducing subsets
  11 and inconsistent configurations. It also shows that with a little extra
  12 knowledge about the program the searching time can be decreased significantly.
  13
  14 %Evidence (what evidence is offered to support the claims?)
  15 Evidence of the claims are presented through showing the performance on a real
  16 life case studies of a small size and big size. Besides the real world
  17 applications the properties of the algorithm are proven in an earlier published
  18 report about the algorithm.
  19
  20 \subsubsection*{Strengths \& Weaknesses}
  21 %Strength (what positive basis is there for publishing/reading it?)
  22 The strengths of the paper is that is an easy read. The reader is slowly
  23 introduced into the theoretical framework to later get clear real world
  24 examples showing the capabilities of the algorithms.
  25
  26 %Weaknesses
  27 Weaknesses are that the writer makes assumptions about the data that are not
  28 supported. For example on Page $255$ it states that worst case you need to test
  29 all $2^n$ configurations. But in practise this almost never is the case. Also
  30 he cites almost no related work and assumes by looking at one related paper
  31 that thus is no related work.
  32
  33 \subsubsection*{Evaluation}
  34 %Evaluation (if you were running the conference/journal where it was published,
  35 %would you recommend acceptance?)
  36 The author is very clear about the strengths and weaknesses of the proposed
  37 methods. It even provides a full implementation. I would recommend acceptance,
  38 but possible only after more related work was found.
  39
  40 %Comments on quality of writing
  41 Concerning quality of writing; the paper is an easy read and is a good mix of
  42 formal descriptions and natural language. Also the structure of the paper is
  43 clear and it navigates the reader in a natural order through the materials.
  44 It's not very deeply embedded in the literature, this was already mentioned in
  45 the introduction.
  46
  47 \subsubsection*{Discussion}
  48 %Queries for discussion
  49 \begin{itemize}
  50         \item Page $255$ states that worst case you need to test all $2^n$
  51                 configurations. But in practise this almost never is the case. Is this
  52                 really almost never the case? This is not obvious since is other fields
  53                 of computer science, such as time complexity the average complexity
  54                 usually is closer to the maximal complexity than to the minimal
  55                 complexity.
  56         \item Would it be better to research not so much the delta debugging
  57                 algorithm but the heuristics in searching since different clustering
  58                 heuristics give significantly different results.
  59 \end{itemize}
  60 \end{document}