cc: hegerl@duke.edu, "Myles Allen" , "Eduardo Zorita" , anders.moberg@natgeo.su.se, weber@knmi.nl, k.briffa@uea.ac.uk, jan.esper@wsl.ch date: Thu, 2 Nov 2006 10:26:34 +0000 from: Martin Juckes subject: Re: CPD submission to: t.osborn@uea.ac.uk Hello Tim, Thanks for that. I have now responded to McIntyre, as he answered my previous email. It is now reasonably clear that he used the centred (but not normalised) principal components for his reconstructions, so the error in his figure 2 is isolated. It is however, relevant, because he uses that figure to disparage the MBH PC calculation. I appreciate your point about MM03, but there are two important differences: (1) MM03 was entirely focussed on MBH98 and (2) our paper is published in a discussion forum. Our paper is not entirely or mainly focussed on McIntyre and McKitrick's work and we have not consulted with the authors of all the papers we comment on. As we are presenting principal components which ae clearly inconsistent with that published in MM2005c, figure 2, and as we KNOW (by which I do not mean suspect, think, or believe) that a graph with non-zero mean (as displayed in figure 2) cannot be a PC of centred data I cannot understand why you and others are reluctant to state the obvious. Regarding Eduardo's recent email: there are several ways of making errors and it is only by looking at the code that I know which particular route they took in this case (namely, using a function which does not do centering). Calling something which is not a PC a PC would be a potential source of error, but what they have actually plotted (see the pdf I attached a few emails back) is the PC of uncentred data. Changing the definition of a principal component at this point is not going to be helpful. I can see, however, the advantage of keeping things brief, as in Nanne's suggested text. I think we do, however, need to replace a comment based on the then unavailable code with a comment about the code that is now available, so I've added a couple of lines to that effect, and also a line giving McIntyre credit for disclosing more code than most (which is a good thing in itself, even if we don't believe that everyone is in a position to do it). So I suggest the following text: ================================================ CORRECTION: On page 19, line 6, the manuscript states: "The code used by MM2005 is not, at the time of writing, available": This comment should have referred to the code used by MM2005c (their Energy and Environment paper) -- the code used by MM2005 (their GRL paper) was made available at time of publication. In view of these considerations the following modification to the text is needed: on page 19, line 6-9: replace "The code .... (standardised)" with: "The code used by MM2005c (available at http://www.climate2003.com/scripts/) shows that they use PCs which have been (except in figure 2) centred but not normalised to unit variance (standardised). Figure 2 of MM2005c is an exception: it shows a graph with non-zero mean which cannot be the principal component of centred data." We apologise to McIntyre and McKitrick for suggesting that the code for MM2005 was unavailable when it was in fact the code for MM2005c which we had not been able to obtain, and note that they have made efforts to provide code for this and other publications which go beyond the norm in this field. The code used by MM2005c is now (mostly since March 2006, updated October 2006 following correspondence about missing components) available at http://www.climate2003.com/scripts/ (McIntyre, personal communication), as stated in our corrected text above. At the present time this page is not linked to from the main site (www.climate2003.com), which contains the statement that ``The computer script used to generate the figures and statistics in the E\&E here will be located here [in a couple of days]'' Our intended comment (that the code used by MM2005c is not available) was based on the above statement and on an email from Stephen McIntyre to us saying that he would forward the code when it became available. He first informed us of its availability after the publication of our manuscript. In view of these considerations the above statement will be removed from the text when revising the manuscript. A detailed discussion of the provided code can be found on the MITRIE project website (http://mitrie.badc.rl.ac.uk), in addition to some comments on the issue of disclosing software. ======================================================= I'd like to have a consensus on this, but I don't want to waste time discussing whether a figure which must have zero mean and clearly does not is in error or not. There is of course an issue about how to phrase what we say about it .... cheers, Martin On Thursday 02 November 2006 09:38, Tim Osborn wrote: > On Thu, November 2, 2006 8:41 am, Martin Juckes wrote: > > Please respond to this point: a principal component of centred data has > > zero > > mean. > > Martin, > > yes, this point is mathematically correct. Each PC time series is a > weighted mean of the time series at each point in the field, and if each > of those has zero mean, then of course each PC will have zero mean. I > agree. So I don't expect McIntyre to argue against this basic point. But > I complained publicly that MM03 should have been sent to MBH for comment > before it was published, in case MBH had simple explanations for some of > the complaints made in MM03. Which is why I now suggested that you > question McIntyre prior to posting it publicly on CPD. Yes it is a basic > point, but it would be good to know what his response might be in advance > of posting it publicly, so that you can make sure that the way you have > worded the posting already deals with any obfuscation that he might later > attempt. You don't need to mention that you will be posting a comment on > this; it is sufficient to say that, now you have his code, you have looked > into it and it does not seem to centre the data prior to the PCA, and this > is contrary to... etc. and can he clarify the matter. > > Regarding the CPD posts, it might be simplest to post 3 separate pieces: > (1) providing the update with regards code availability, which I guess we > can all sign; (2) discussing data/code availability; and (3) after getting > a response from McIntyre, pointing out the centering problem with his > code/results, which some of us might sign depending on McIntyre's > response. By splitting them this way, there is no need to wait for (3) > before posting (1) and (2). > > Presumably the manuscript itself will be changed after the > review/discussion phase, but for now we just leave it as submitted and > post these comments separately? I wonder if McIntyre will complain that > the manuscript itself will retain the complaint about code unavailability > until the revision phase? > > Cheers > > Tim > > > >