Dear Philippe, find below my comments and questions to your comment. Most I incorporated anyway. > But first some formatting issues. For this edition, we are also compiling a > glossary with keywords or terms that can use some explanation. These terms > should be formatted as bold+italics the first time they are mentioned in the > chapters. OK. > Bold or Italics separately can be used to put other emphasis. At the moment I used bold to highlight important words and definitions, as in the first edition. Do you have any preference for those? better bold or italics or none at all? And do you want to have the fonts set for every mentioning in the text or only the first one? (This might differ for important words, formated only on first mentioning, and glossary words, presumably formated bold+italics thoughout the book.) > I have compiled a list of such terms for your chapter (see attachment), it > would be great if you could format then as required in the text. Many of > those are also occurring in other chapters and have already an explanation. > I'd appreciate it if you could complete it. Please feel free to comment on > others or add other terms you think suitable in your chapter. I will do that. > It would also be useful if you could format the program names in courier, > similar to program options and input files. So you also want to have the program packages names in Courier even these might not be identical to the actual executables? (e.g., TREE-PUZZLE/puzzle, IQPNNI/iqpnni, fastDNAam/fastdnaml, PHYML/phyml, ...) At the moment I already used Courier for files, executables, and commandline and menu-specific stuff like options. DNAML is the only exception where I used a program's name from a whole package. Just specify as you want it. > Minor comments ------------ > On page two, in the sentence: > >From elementary calculus, it is known that relative extrema of a function, > f(x), occur at critical points of f, i.e., values x0 for which either f0(x0) > = 0 or f0(x0) undefined > Is there a need to put 'is' before undefined? OK, done ------------ > In figure 2, it could be appropriate to put a '.' or 'x' in the numbers on > the Y-axis done and changed the mis-typed 10^-94 at the bottom to 10^-93 ------------ > In page 3 you refer to likelihood based testing in Chapter 8 and 10. It is > not discussed in the theoretical section of the PAUP* chapter, but it is > mentioned in the practice. The reference can also be expanded to Chapter 11 > (molecular clock), chapter 12 (your tree testing), so basically the whole > section on hypothesis testing, and chapter 14 (selection). I wrote now: ...discussed more or less detailed in Chapters 8, 10-12, and 14. OK? ------------ > On page 5, you mention that the example was 'completely computable'. It > might be more appropriate to state 'analytically solvable' since computable > seems to general as problems that cannot be solved analytically can still be > computable using numerical methods. Hmmm, that Arndt and I aggreed that this is a bit nit-picking. In my opinion "computing" means getting exact an exact solution, while "computable using numerical methods" means to be "inferred" or "estimated" but not "computed". However, it's changed as you suggested. ------------ > On page 7 you state: > Because the model M is a submodel of the GTR class =AD that is, a > time-reversible model (see Chapter 4) =AD it is assumed that evolution started > from sequence S0 and then proceeded along the branches of tree with branch > lengths d1, d2, d3, d4, and d5. > I understand what you mean, but it could be useful to be more explicit, for > example: > Because the model M is a submodel of the GTR class =AD that is, a > time-reversible model (see Chapter 4) =AD we can assign any point as a root to > the tree. Here, we will assume that evolution started from sequence S0 and > then proceeded along the branches of tree with branch lengths d1, d2, d3, > d4, and d5. I changed it to: ...we can assign any point as a root to the tree for the computation of its likelihood (Pulley Principle, cf. Felsenstein, 1981). Here, we will assume that evolution started from sequence S0 and then... ------------ > In the legend of 6.4 it could be instructive to expand on the example after > the sentence: The values Lij(s) at the leaves are computed with Eq. 6.16, > those at the internal nodes with Eq. 6.15. > With: For example, to obtain the value Lj(C) at node five, equation 6.16 > reduces to Pcc*Pcg or (0.0314*0.9058). added ------------ > On page 10, you state: "The number of (unrooted) tree topologies can be > computed for n sequences according to" > Again to make things more explicit you could say: The number of (unrooted) > tree topologies increases explosively with the number of taxa (n) and can be > computed according to I changed that but used "tremendously" instead of "explosively". ------------ > In addition to Chapter 8, you could also refer to Chapter 5 for > neighbor-joining and star decomposition (page 10). Extended (according to the order in the preceeding sentence, not the order of numbers) to: These methods are discussed in Chapters 8, 10, and 5, respectively ------------ > The reference to Chapter 13 on page 14 should be Chapter 14 instead done ------------ > On page 10, you introduce heuristics, including stepwise addition but use > the term stepwise insertion in the next paragraph. It would be better to be > consistent, isn't stepwise addition a more frequently used? I prefer 'stepwise insertion', but google supported your view. So I changed it ;-) ------------ > In paragraph 6.4.1 you explain stepwise addition using: > The algorithm proceeds as follows: One randomly selects three taxa from the > list of n taxa, then one reconstructs the corresponding maximum likelihood > tree > However, there is only a one possible unrooted topology for three taxa. So, > what about: > The procedure starts from the unrooted tree topology for three taxa randomly > selected from the list of n taxa. It is about the branch lengths as well actually... but you have a point there. changed ------------ > On page 11: > and tree-bisection and reconnection (TBR), (confer Figure 6.5 and for > details Chapter 8. > Suggestion: > and tree-bisection and reconnection (TBR) (confer Figure 6.5 and for > details, see Chapter 8). I don't like the brackets ') (', so I just removed the opening bracket. OK? ------------ > >From the explanation of DNAML and fastDNAml, it is not clear why one should > be 'fast'DNAml. In fact, if fastDNAml can do rearrangements during the > addition process, one would think that it would be slower. Do you think it > is worthwhile that the recoding of DNAML into fastDNAml resulted in a faster > and more memory efficient program? The program is called fastDNAml. That actually was not motivated by changes and additions in the method, but it was much faster than DNAML at that time for the following reasons: - DNAML was implemented in PASCAL when Olsen at el. ported it to C - DNAML did unfortunate bookkeeping during SPR with step width one. In a tree AB|CD moving subtree A to the branch leading to C is identical to moving subtree D to the branch leading to B and DNAML didn't check for that. Hence, DNAML evaluated twice as many rearrangements than necessary ;) Also DNAML has undergone change since the mid-90ies, but still I wouldn't use it for large data. It is outperformed by too many programs. (This didn't imply changes to the text.) ------------ > >From the explanation of simulated annealing, it was interesting to notice > how conceptually similar this to an MCMC approach. Maybe this could be > pointed out as follows: > One starts with an initial tree, then samples the tree-space by accepting > with a reasonable probability a tree with a lower likelihood (down-hill > move). Trees with higher likelihood (up-hill moves) are always accepted. > This conceptually similar to Markov Chain Monte Carlo approaches (see > Chapters 7 an 18). However, as the process continues the down-hill > probability is decreased. I changed it to: This is conceptually related to Markov Chain Monte Carlo (see Chapters~7 and 8). However,... I used "related" instead of "similar", since there is relationship not just simililarity by chance. ------------ > In paragraph 6.5, you mention that if similar trees are constructed one > tends to trust the result. Maybe it would be more careful to say that one > would have more confidence in the result? The verb "tends to" was chosen to be very careful already, so I changed to ...one tends to have more confidence in the result. to keep the "tends to" and get rid of the "trust". > Also: Typically tree reconstruction methods are searching for the best tree, > leaving the user with a single tree and ML value but without any estimate > the reliability of its subtrees. > Is there a need of a 'of' before the reliability? added ------------ > The reference for LRT in the next few lines can also include Chapter 11 and > 14, in addition to 10. added ------------ > The reference for MrBayes on the next page can also include Chapter 7 or, in > your case, the 'next' chapter. done ------------ > If you refer to the file HIValn.phy, could you add: available at > www.thephylogenetichandbook.org added, but... is that correct? The webpage doesn't exist but guess you have 'bought' it already? ------------ > When you discuss the option in iqpnni to change the model of sequence > evolution, it would be useful to add: The model can be selected based on one > of the approaches discussed in Chapter 10. I added: An appropriate model can also be selcted based on one of the approaches discussed in Chapter~10. ------------ > When I repeat the exercise with IQPNNI, I get, not surprisingly, the same ML > tree with the same log likelihood. However, the NNI procedure can find > better trees at different iteration numbers among different runs (but they > all end up at the same ML tree). I presume that is because of the stochastic > component of the algorithm. To avoid confusion for people repeating the > example, it might be useful to point that out. And by pointing it out , you > could aslo argue that the procedure doesn't get stuck in a local optimum for > this example. I added: Repeating the example will produce slightly different output, that means, the best tree might be found in different iterations. This is due the stochastic component in the the IQPNNI procedure (cf. Section~\ref{sec:iqpnni}) when randomly removing and then re-inserting taxa into the tree. I also re-did the IQPNNI analyses, since there is version 3.2 now, which uses more default iterations: max(200, 2*taxa, 20*number of parallel CPUs) Hence, I had to change the sentence about the finding of the best tree, but also made clear, that NNI-only based mathods might get trapped. ------------ > When I run the tree-puzzle example, there is an additional line in the > screen output: Writing tstv to file hivALN.phy.tstv Yes, true. For the Leipzig workshop we added the output of distances together with the observed transitions and transversions. Now we can do the ts-tv plot with R to check for saturation even if DAMBE is not available. (We were running the workshop under Linux ;) > More importantly, different runs will results in different numbers of > intermediate trees. I usually get a number around 380 trees. The number of intermediate trees constructed was always the same, but since the addition orders are created randomly the number of unique tree topologies varies slightly due to the stochastics involved. > I assume the > different numbers are due to different random quartet samples and therefore > different intermediate solutions? Again, it would be useful to point this > out to the reader and mention that just like bootstrapping their will be > some stochastic component in the support values. I added the following for quartet puzzling: Similar to bootstrap analysis (cf. Chapter~5), the resulting intermediate trees and, hence, the resulting support values might differ slightly due to the randomization of the insertion order in the puzzling step (cf. Section~\ref{sec:qp}). Consequently, also the number of unique intermediate tree topologies and their percentages will also vary slightly. Please note, the intermediate tree found most often does not necessarily coincides with the maximum likelihood tree, but often the ML tree is among the intermediate trees. I added the following for likelihood mapping: [...good resolution is expected.] Nevertheless, the percentages of up to $4.9\%$ unresolved quartets still implies a conciderable amount of noisy or conficting signal in the dataset. Please note that, if the likelihood mapping is repeated on a ramdom subset, the resulting percentages may naturally differ slightly. I separated the following to a section "Conclusions", since this makes more sense than being together in one section about likelihood mapping. Hence, I added one or two sentence to make it a more proper comparison and also added the reference of you paper. ------------ > When the likelihood computation is performed for all intermediate trees, I > think it is useful to point out that the most frequently found intermediate > tree topology is not necessarily the tree with the best log likelihood. On > the other hand, the ML tree in the list of intermediate trees is identical > to the topology of the qpnni search. So, both heuristics arrive at the same > solution Yes, but hivALN.phy is not a tooo difficult dataset, though containing recombination. ------------ > On page 29, you discuss the polytomy in the consensus tree from tree-puzzle. > Interestingly, you suggest that intersubtype recombination might be > responsible for this. Well, it has been recently demonstrated that subtype G > is a intersubtype recombinant strain. This strain is involved in the > polytomy. Therefore, it might be interesting to refer to this finding. The > reference is: > Abecasis, A. B., P. Lemey, N. Vidal, T. de Oliveira, M. Peeters, R. Camacho, > B. Shapiro, A. Rambaut, and A. M. Vandamme (2007). Recombination is > confounding the early evolutionary history of HIV-1: subtype G is a > circulating recombinant form. J Virol. [Epub ahead of print] The latter speculation from the first edition of this book (von Haeseler and Strimmer, 2003) was recently substanciated by findings of \citet{abecasis2007} that subtype G might be a recombinant instead of a pure subtype as previously thought.