In comments, FrancisT has a link to his in depth look at just a couple of the comments in “HARRY_READ_ME”. Well worth a read:
http://www.di2.nu/200911/23a.htm
Oh, and I’ve added a bit of time stamp forensics in a comment near the bottom too.
Original Article
From:
http://www.neuralnetwriter.cylo42.com/node/2421
We have [begin quote]:
The bit that made me laugh was this bit. Anyone into programming will burst out laughing before the table of numbers
Quote:
17. Inserted debug statements into anomdtb.f90, discovered that
a sum-of-squared variable is becoming very, very negative! Key
output from the debug statements:
OpEn= 16.00, OpTotSq= 4142182.00, OpTot= 7126.00
DataA val = 93, OpTotSq= 8649.00
DataA val = 172, OpTotSq= 38233.00
DataA val = 950, OpTotSq= 940733.00
DataA val = 797, OpTotSq= 1575942.00
DataA val = 293, OpTotSq= 1661791.00
DataA val = 83, OpTotSq= 1668680.00
DataA val = 860, OpTotSq= 2408280.00
DataA val = 222, OpTotSq= 2457564.00
DataA val = 452, OpTotSq= 2661868.00
DataA val = 561, OpTotSq= 2976589.00
DataA val = 49920, OpTotSq=-1799984256.00
DataA val = 547, OpTotSq=-1799684992.00
DataA val = 672, OpTotSq=-1799233408.00
DataA val = 710, OpTotSq=-1798729344.00
DataA val = 211, OpTotSq=-1798684800.00
DataA val = 403, OpTotSq=-1798522368.00
OpEn= 16.00, OpTotSq=-1798522368.00, OpTot=56946.00
forrtl: error (75): floating point exception
IOT trap (core dumped)
..so the data value is unbfeasibly large, but why does the
sum-of-squares parameter OpTotSq go negative?!!
[end of quote and quoted quote ;-) ]
For those unfamiliar with this problem, computers use a single “bit” to indicate sign. If that is set to a “1″ you get one sign (often negative, but machine and language dependent to some extent) and if it is “0″ you get another (typically positive).
OK, take a zero, and start adding ones onto it. We will use a very short number (only 4 digits long, each can be a zero or a one. The first digit is the “sign bit”
. I’ll translate each binary number into the decimal equivalent next to it.
0000 zero
0001 one
0010 two
0011 three
0100 four
0101 five
0110 six
0111 seven
1000 negative (may be defined as = zero, but oftentimes
defined as being as large a negative number as you can
have via something called a 'complement'). So in this
case NEGATIVE seven
1001 NEGATIVE six
1010 NEGATIVE five (notice the 'bit pattern' is exactly the
opposite of the "five" pattern... it is 'the complement').
1011 NEGATIVE four
1100 NEGATIVE three
1101 NEGATIVE two
1110 NEGATIVE one
1111 NEGATIVE zero (useful to let you have zero without
needing to have a 'sign change' operation done)
0000 zero
Sometimes the 1111 pattern will be “special” in some way. And there are other ways of doing the math down at the hardware level, but this is a useful example.
You can see how adding a digit repeatedly grows to a large value (the limit) then “overflows” into a negative value. This is a common error in computer math and something I was taught in the first couple of weeks of my very first programming class ever. Yes, in FORTRAN.
We have here a stellar example of it in real life in the above example where a “squared” value (that theoretically can never become negative) goes negative due to poor programming practice.
There are ways around this. If a simple “REAL” (often called a FLOAT) variable is too small, you can make it a “DOUBLE” and some compilers support a “DOUBLE DOUBLE” to get lots more bits. But even they can have overflow (or underflow the other way!) if the “normal” value can be very very large. So ideally, you ought to ‘instrument’ the code with “bounds checks” that catch this sort of thing and holler if you have that problem. There are sometimes compiler flags you can set to have “run time” checking for overflow and abort if it happens (there are also times that overflow is used as a ‘feature’ so you can’t just turn it off all the time. It is often used to get “random” numbers, for example.)
But yes, from a programmers point of view, to watch someone frantic over this “newbie” issue is quite a “howler”…
And that is why I’ve repeatedly said that every single calculation needs to be vetted for rounding, overflow, underflow, precision range, …
Because otherwise you are just hoping that someone did not do something rather like they clearly have done before…
Also, from :
http://wattsupwiththat.com/2009/11/20/mikes-nature-trick/
we have in comments:
Paul W (15:05:29) :
Phil Jones writes that the missing raw CRU data could be reconstructed:
(from file 1255298593.txt)
From:
[email protected]: “Rick Piltz” <
[email protected]
Subject: Re: Your comments on the latest CEI/Michaels gambitDate: Sun, 11 Oct 2009 18:03:13 +0100 (BST)Cc: "Phil Jones" <
[email protected]
, "Ben Santer" <
[email protected]
Rick, What you've put together seems fine from a quick read. I'm in Lecce inthe heal of Italy till Tuesday. I should be back in the UK byWednesday. The original raw data are not lost either. I could reconstruct what wehad from some DoE reports we published in the mid-1980s. I would startwith the GHCN data. I know that the effort would be a complete wate oftime though. I may get around to it some time.
So we have a tacit confirmation that they start with GHCN data. That means that ALL the issues with the GHCN data (migration to the equator, migration from the mountains to the beaches…

apply to Hadley / CRU just as they do to GIStemp.
Both are broken in the same way, so that is why they agree. They use biased input data and see the same result.
Heck, I’ve even stumbled onto another programmer type doing stock trading stuff…
The discussion is very interesting, even if a bit ‘rough language’ at times:
http://www.tickerforum.org/cgi-ticker/akcs-www?post=118625&page=13
In comments there we get a picture of “Mr. Harry Readme”:
http://www.cru.uea.ac.uk/cru/people/photo/harry.jpg
Somehow, I can feel his pain at the code he must deal with. Best of Luck to you Harry.