I could say something snarky like ” Yer all pansies, I used to toggle binary programs into an Altair MITS on the front panel and read the output from the blinky lights”… or mention the time I learned “APL” out of curiosity (and wrote a program about 40 characters long that did about 5 pages worth of work – but they don’t call it a “write only” language for nothing, the next day I couldn’t read it… Yeah, that APL, the one that needs a custom keyboard with hieroglyphics on it … Ah, the days… I’m SO glad they are gone

After that stuff, FORTRAN is positively God’s Gift.

OK, with that out of the way, I took the approach of minimal change and just made GIStemp go. I also wanted to be able to throw rocks at it without having to defend too much against the “You must have changed it!” accusation.

It’s up. It’s running. You need a LINUX or UNIX box (I’m on Red Hat 7.2 with a 400 Mhz AMD chip and about 128 MB of memory IIRC) and the changes needed are minimal. (Mostly just not using one non-standard data declaration – i.e. move the data initialization out of the variable declarations and into a DATA statement). I’m happy with that choice. And matching each chunk to the compiler for it’s era. f77 for some, g95 for others.

Now I can, at my leisure, rewrite any part of it into C (or whatever), do an A/B compare, and proceed with confidence that I have not changed anything enough to matter or to need defending.

If anyone wants a working copy, let me know at my site. I’ve only translated one small test program to C to check how hard it is (not too bad). The biggest issue I’ve run into is that the Hadley SST files are “Bigendian” and a PC is “littleendian” and FORTRAN “unformatted” files are actually quite formatted and in an odd way that endian swaps make hard to handle in C. (It writes a byte count, the sometimes variable length bytes, then the byte count AGAIN. You can’t just blanket unswap the bytes… you must know the FORTRAN layout of the data. i.e. an INT takes a different byte count that a LONG INT to be reversed.) See:

http://local.wasp.uwa.edu.au/~pbourke/dataformats/fortran/

then weep… “what were they thinking” indeed… and do you really want to try to unscramble that in C ?

A decent starting point is at:

http://chiefio.wordpress.com/2009/07/29/gistemp-a-cleaner-approach/

Where I talk about the changes I made to the directory structure, the change to a Makefile design, and that it works with less confusion this way.

Oh, and I’d suggest NOT dredging your brain through their code if possible. The damage it has done to my coding style will take a couple of years to purge. You can’t steep yourself in someone else’s stuff for months on end without starting to code in their “accent”… A major part of my goal has just been to get most of it so that folks can look at a chunk, re-write it sanely, do an A/B, and then move on. The whole STEP0 ought to just be a few data load scripts into a decent relational database.

E. M. Smith

I had a full copy at the time, though I do not recall where it was. I had a rather catastrophic HDD crash around December, 2007, so I lost a lot of that peripheral stuff I had been working on. From what I understand, the code as it was at the time, is no longer available. You and Jean S have copies, right?

If they had done it in the Fortran of MBH98, I’m guessing an obfuscated code contest contribution suggestion would have been in order?

Mark

Steve: see http://holocene.meteo.psu.edu/shared/research/MANNETAL98/. I’ve copied it as well/

The Mann analyses only take time because the code was beyond horrendous.

But because it was done in Matlab – you could sort of follow what they were trying to do. Now that we’ve pretty much figured out RegEM, we need to revisit it. If they’d done it in the Fortran of MBH98, it would have been totally unintelligible.

But the context, obviously, is the sort of statistics being done in here, for which, Steve is correct. None of these sorts of analyses require real-time execution speeds.

Mark

For statistical applications, the speed of execution is pretty much irrelevant.

That would depend on the nature of the statistics being sought.

For statistical applications, the speed of execution is pretty much irrelevant.

The costs are programming and analysis, where the gains from using high-level languages such as R or Matlab, vastly outweigh any slight benefits in execution speed from using assembly language or Cobol or Fortran.

Is the code available to the public?

What code?

R is great, but it is still an interpreted language. Fortran and Matlab code can be compiled into machine code executables.

There are ways to optimize R performance, but the best would be if the R project would be extended to have a fullfledged compiler (and other tools would be great too).

Long ago (seems almost like another life) I did a fair amount of FoxPro (PC database) programming, a variant of dBase. You could use it in interpreted mode, or build compiled programs for maximum speed. I think Matlab has that capability, giving it a significant advantage over R.

Is the code available to the public?