Cheers, — Jo Calder

The target data is not as autocorrelated as some of the proxy regressors – see the warnings of Ferson et al for this type of situation.

In a sense, it would reduce the errors, but you’re assuming that there is a “right” answer. My impression is that you have an unsavory combination of spurious regression and multilinear overfitting, creating quite a unique witches brew, the statistical properties of which are not understood by the authors.

But in the RegEM version, their “target” instrumental version for MBH is one year off. So they get essentially the same reconstruction regardless of whether they get the instrumental year right. !?!?!

Is there some indication of the scale of the errors this induces (I guess some measure of year-to-year variation)? OTOH if the data is highly autocorrelated, wouldn’t that tend to reduce the consequent errors?

I had the thought, further to this thread and G Schmidt’s comment about the unsuitability to Climate Research of any archive mechanism yet devised, that this site could offer a service to archive researchers’ SI code and have it debugged by willing volunteers. A similar pre-publication service might be more generally appreciated.

Cheers, — Jo Calder

They didn’t make the instrumental collation error in the script combinedstepwiselowrecon2.m, which splices in the instrumental record as follows:

composite(457:599,1:1008)=respliced(:,1:1008);

The difference in splices is final proof of the cock-up in their MBH98 version. I’m surprised that there’s not been more piling on by readers with respect to the collation error in the Rutherford et al [2005] implementation of MBH98. I think that it’s going to be a big deal in a couple of ways.

First, on an elementary basis, it’s a pretty humiliating error – both in itself and given all the discussion arising out of MM03 and collation errors and supposedly "wrong" data sets. I guess that they will suddenly announce that they posted up the "wrong" script and that anyone who was less stupid than me would have known enough to consult the "right script" which was really up all the time in some other location never previously mentioned and delete the "wrong" script. But it will be pretty tough to get away with this a second time.

Secondly, think about what it means for MBH98. They have proudly announced that they get essentially the same results as MBH98 using a "completely different" method RegEM. (I’m going to do a post on whether RegEM is really a "completely different" method or whether the linear algebra ends up boiling down to being pretty similar in the 15th century.) But in the RegEM version, their "target" instrumental version for MBH is one year off. So they get essentially the same reconstruction regardless of whether they get the instrumental year right. !?!?!

This is completely consistent with our understanding of MBH methods – a classic spurious regression of the bristlecones combined with massive "overfitting" from essentially white noise series in the calibration period, thus the breakdown of the cross-validation R2. I’ve shown a little how this works in Huybers #2, which has never attracted as much comment as I’d hoped, but really need to articule this in a longer form.

That just leaves me to rant about pet peeves in MatLab code, highlighting an observation from Phil. One of the things I am particularly critical of is when people use the variables “i” and “j” in matlab code – particularly in scripts where variable scope is loose – as both of those tokens have built-in definitions, in particular they represent the square root of -1. Once they have been declared as variables, the variable use overrides the constant, but it does not make for easy reading of the code.

Of course the use of these as variable names is a hang over from Fortran, in which they are commonly used as integer loops. When anyone writing code for me does this I tell them to go away, and bring it back to me when they have used meaningful variable names!

OK this is a little bit petty, these guys are scientists, not software engineers, and these are short routines so there is not so much of an issue with sloppy code, as long as the code runs and gives the right answer.

Shame it didn’t do that either…

http://www.theinquirer.net/?article=29457