18 March 2009

Read original sources

I've mention it here and there before, but was reminded recently of the importance of reading the original sources. The recent round was a document which said the IPCC had not discussed some points about sea surface temperature. I thought that was odd, so I looked up the IPCC section that talks about sea surface temperature (SST) and in truth, they do talk about those issues. If somebody is lying about what someone else says in such an easily identified way, time to pitch that original source and go looking for someone honest to learn from. So that's one reason to read the original sources -- to see who's lying and weed them out.

There are also more pleasant reasons to follow up to original sources. One is, often the source is being cited for something that's a minor part of what they were talking about -- and the major part is even more interesting. In oceanography, one of the things often mentioned in classes is the Ekman Layer. Don't worry about what it is exactly. Usually, a reference says that Ekman (1905) studied the formation of what we now call the Ekman layer for conditions of an infinitely deep ocean, infinitely steady winds, with absolutely constant friction through the depth of the ocean. Well, it turns out that, although he did examine that highly idealized case, this was a small part of the paper. In fact he also examined varying winds and varying friction. And the results of doing so were much more interesting than what he's normally cited for.

A second reason can be particularly important in science. In the original papers on an idea, the author is explaining something new to the audience. He can't assume nearly as much as later papers on the idea will. You'll also get to see the first matchups of the idea against observations. So I usually learn more by reading the original than by reading the textbook description. (For the geophysical fluid dynamicists out there -- Charney's paper on baroclinic instability is the one exception I've found. There also turn out to be reasons why it came out that way.)

Part three is that you'll get to see much more discussion of why the approximation can be made, and where it can be expected to fail. So, for example, a modern paper talking about the color of the sky -- perhaps for a planet orbiting some other star -- will merely mention 'We apply Rayleigh scattering law and arrive at ...'. It's only when you read Rayleigh's papers that you find out that the 'law' is an approximation, and it will fail under certain, predictable, conditions.

It can be difficult to get hold of the original sources when you start going after Reynolds 1895, Ekman 1905, etc. So the ideal can't always be met. Still, the whole IPCC working group 1 (physical science) 4th report is readily available online or you can order a print copy (also groups 2 and 3, but I'm a physical science guy, so look more to that one). So, when you encounter someone making claims about what the IPCC says, go take a look yourself. And if the point isn't clear, or it is interesting to you, start following up the citations they give. (Unfortunately, I think that after the first report, the writing declined in terms of readability by nonprofessionals. Any more, once you're past deciding if someone lied about the IPCC, I think you'll have an easier time reading by hitting the cited sources rather than the IPCC reports.)

5 comments:

Scruffy Dan said...

Looks like Jerry is providing you with plenty of good post ideas.

Glad to see that something positive came from our little debate.

Robert Grumbine said...

Folks, Dan is referring to the comments to his post on his blog
Why I accept the scientific consensus on global warming, and what would change my mind

I recommend the original post, as the question 'what would change your mind' is important. As I've mentioned, if the answer is 'nothing', you're not talking science.

Early in the comments, I suggested a way someone could change my mind about the CO2 rise of the last 100 years being from human activity. John, Dan, and I iterated on that some.

Later on, Jerry showed up with some, let's say, not-good questions, and some serious failure to read the original sources. If anyone here thinks the NIPCC document has scientific merit, take a look at the discussion over there.

Yes, Jerry (and NIPCC) have been good sources for article ideas. Someone asked here some time back about what I now see was likely the chapter 6 assertions of NIPCC. The answer I gave then wouldn't have addressed the real question well. And sea surface temperature is now a concern of mine at work, so I'll start up, probably next week, some notes about it.

EliRabett said...

There are two reasons for reading the original reference. One is where you have some idea of what is going on and alarm bells start to ring when you read a translation. In that case you are either going to find that

a. the translation is misleading
b. something new
c. serendipity strikes (for this you need to have a basic idea about the issue)

Eli shortens this to RTFR

the second is where something interests you/you are curious. For that you don't have to get the whole argument, but often the introduction gives you an idea of what is at issue and places to go look for more, also the conclusions

Hank Roberts said...

> and places to go
> look for more

Including the obvious: the footnotes; and the papers that have subsequently cited the paper you're looking at.

I don't think there's anything remotely like that system for software engineering, is there?

John Mashey said...

gmcrews:

Software engineering (at least in the sense of learning to use a new language) != science.

In either one, of course one starts with tutorials, then goes into more detailed pieces.

Computer languages are *created* things, not *discovered* things, and are usually a lot better defined. They don't usually come with error bars, missing data, etc, etc.

On the other hand, if you need to *implement* a C compiler and runtime, you may wish to consult the ANSI C spec, or go even deeper to understand *why* things are as they are, and how to avoid future problems.

For example, see The Long Road to 64-bits, specifically the part about C on 64/32-bit CPUs. Even the ANSI C Rationale (section for long long) is only a brief summary of the various papers written.

When doing software/computer history, one often needs to go back to the originals to figure out what was really going on. Quite often, later summaries lose that.