Consensus? How could anybody consent to this temperature trend garbage

[polarbear]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
https://wikileaks.org/wiki/Climatic_Research_Unit_emails,_data,_models,_1996-2009
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

 

[Slade3200]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

So you don't think there has been a global increase in temperature? Ocean temp rises?

 

[daws101]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

So you don't think there has been a global increase in temperature? Ocean temp rises?

Obviously not, hence the dramatic red lettering.

 

[skookerasbil]

indeed.......there are about 4 billion threads in this forum that document the rigging of the data.

 

[daws101]

indeed.......there are about 4 billion threads in this forum that document the rigging of the data.

4 billion?
No wonder you're a climate change denier.

 

[jc456]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

So you don't think there has been a global increase in temperature? Ocean temp rises?

nope to both.

 

[jc456]

indeed.......there are about 4 billion threads in this forum that document the rigging of the data.

4 billion?
No wonder you're a climate change denier.

He's utilizing the same procedure as the supposed experts in data collection.

 

[daws101]

indeed.......there are about 4 billion threads in this forum that document the rigging of the data.

4 billion?
No wonder you're a climate change denier.

He's utilizing the same procedure as the supposed experts in data collection.

False! he's posting shit.

 

[Slade3200]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

So you don't think there has been a global increase in temperature? Ocean temp rises?

nope to both.

So you think the many many stories like this one that's happening in my hometown are just made up?

http://m.kionrightnow.com/harbor-seal-population-drops-in-monterey/41174870

 

[jc456]

indeed.......there are about 4 billion threads in this forum that document the rigging of the data.

4 billion?
No wonder you're a climate change denier.

He's utilizing the same procedure as the supposed experts in data collection.

False! he's posting shit.

which is the same as those who collect data.

 

[jc456]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

So you don't think there has been a global increase in temperature? Ocean temp rises?

nope to both.

So you think the many many stories like this one that's happening in my hometown are just made up?

Harbor seal population drops in Monterey

I expect that this latest one is indeed photographed correctly why the seal population is dropping is made up, yes!

 

[Ozone]

if we rounded up all the people who believe in ''scientific consensus'' and exterminated them, that might actually save the earth.

 

[Slade3200]

Found this in the downloaded wikileaks files which can be found here
Climatic Research Unit emails, data, models, 1996-2009 - WikiLeaks
In an internal communication concerning the temperature trends you can see just how bogus the temperture trends and the source data these are based really are in this "read me.txt" file. It is very very long but if you scroll through it you will get the picture:

Producing anomalies
Subscript out of range on file line 1011, procedure programs/fortran/update.for/MAIN.
OH FUCK THIS. It's Sunday evening, I've worked all weekend, and just when I thought it was done I'm
hitting yet another problem that's based on the hopeless state of our databases. There is no uniform data integrity, it's just a catalogue of issues that continues to grow as they're found.

Probably the worst story is temperature, particularly for MCDW. Over 1000 new stations! Highly
unlikely.
So, just tadj to 'fix', then? Though surely I should read the 2006 tmp & dtr the same way.
Or is it that I copied the 61-90 over from here, but generated the 2006 there

Oooops. Lots of wild values, even for TMP and PRE - and that's compared to the previous output!! Yes, this is comparing the automated 1901-2008 files with the 1901-June2006 files, not with CRu TS 2.1.
minmax rd0 2.5 binaries: -100.000 357.327
minmax rd0 2.5 binaries: -94.2232 250.621
minmax rd0 2.5 binaries: -93.0808 512.557
minmax rd0 2.5 binaries: -100.000 623.526
minmax rd0 2.5 binaries: -95.1105 521.668

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

minmax rd0 0.5 binaries: -1.00000 8.33519
minmax rd0 0.5 binaries: -0.970328 8.13772
minmax rd0 0.5 binaries: -0.951749 4.33032
minmax rd0 0.5 binaries: -1.00000 9.26219
minmax rd0 0.5 binaries: -0.960226 3.80590

There was something very fishy about that run.
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904021239/conv.mcdw.0904021239.dat
9 1994 12 2008
crua6[/cru/cruts/version_3_0/update_top] cat runs/runs.0904151410/conv.mcdw.0904151410.dat
1 2009 1 2009

Also of interest - how did the program find a 2000-2009 station when the previous update was to 2008?
The CLIMAT update did it!! It's that bloody no-metadata problem!!
crua6[/cru/cruts/version_3_0/update_top] ./metacmp
METACMP - compare parameter database metadata
RESULTS:

Matched/unopposed: 2435
Clashed horribly: 4077

Ouch!
It's all synthetic from 1990 onwards.



These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies.
So there you have it. The trends this so called "adjusted and corrected" data which is published pretending to be within a 1/10th degree accuracy turns out to be utter garbage.
It is also quite clear that these so called experts can`t even properly assemble the temperature data but go on and fabricate some sort of temperature anoma- lies that 97% of them consent to.

So you don't think there has been a global increase in temperature? Ocean temp rises?

nope to both.

So you think the many many stories like this one that's happening in my hometown are just made up?

Harbor seal population drops in Monterey

I expect that this latest one is indeed photographed correctly why the seal population is dropping is made up, yes!

 

[daws101]

indeed.......there are about 4 billion threads in this forum that document the rigging of the data.

4 billion?
No wonder you're a climate change denier.

He's utilizing the same procedure as the supposed experts in data collection.

False! he's posting shit.

which is the same as those who collect data.

Nope.

 

[Crick]

if we rounded up all the people who believe in ''scientific consensus'' and exterminated them, that might actually save the earth.

I've added you to my collection of denier death threats and suicide requests.

 

[Crick]

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.

Rounded to integer? Were you under the impression that floating point values cannot be represented in binary code?

 

[polarbear]

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.

Rounded to integer? Were you under the impression that floating point values cannot be represented in binary code?

As usual you are mouthing off about something which is obviously way above your head, like the fortran program this computer programmer was trouble shooting.
You asking me :"Were you under the impression that floating point values cannot be represented in binary code?"
shows just how stupid you really are.
The person who examined the program realized that all the floating decimal numbers they input into their data base have been ROUNDED to a binary INTEGER.
Since you are a dummy I`ll give you an example:
rounding the floating point decimal number 242.789 to a binary integer gives you a binary number : F2
which is the ROUNDED number 242 with no decimal place
And that`s what the rd0 command did....and he realized that this applied to their whole data base
And you come back with the stupid question asking me if I knew that floating point decimal values can be represented as binary.
btw. Is that you?

 

[Crick]

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

rd0 is a separate problem from "written to binary... rounded to integer"

I learned FOTRAN on an IBM360 mainframe in 1967. The problem here was not my comprehension of FORTRAN, but the formatting of your post.

 

[polarbear]

The trouble is, when written to binary, these will be rounded to integer and a degree of accuracy will be lost.
Then there's the 0.5-degree converter
(rd0_gts_anom_05_m.pro), which has indescribably awful output values:

rd0 is a separate problem from "written to binary... rounded to integer"

I learned FOTRAN on an IBM360 mainframe in 1967. The problem here was not my comprehension of FORTRAN, but the formatting of your post.

If that`s really true, which I doubt then you should have known how a decimal number is converted to binary and you should also have been familiar with the associated cmd. fortran compilers use.
You are contradicting just for the sake of contradiction as some sort of habit usually associated with immature individuals.
Now it`s not the substance but the format of my post.
Read it again I posted:
"These are not my words, everything in red is in this internal communication regarding the program that is used to calculate the temperature anomalies."

 

[Crick]

I noted that the second time around. I didn't see it the first time through and it seems sort of an odd comment to make on a post. To be honest, I wondered if you'd added it after seeing my comment.

I do know how decimal numbers are represented in binary. I also assumed someone doing graduate level scientific research would also know how. Thus, the comment makes no sense in that context.

But, to move back to the point, do you believe that this one post invalidates all the world's temperature records? Do you, by chance, have the RESPONSES to that comment?