Conference papers

I've just finished reviewing a pile of papers for some upcoming conference: IJCNN 2014, and EAIS 2014. While these papers represent some good work, in some cases their presentation leaves a lot to be desired. After spending my post-doc career in ecology, I have come to the conclusion that authors in our community could learn something from the way papers are written in other sciences.

In the sciences, a paper has five-six sections: the abstract; introduction; methods; results; discussion; and sometimes conclusions. Each of these sections has a specific function, and these functions fit papers in computational intelligence just as well as other sciences. Now, computer science in general and computational intelligence in particular is fairly unusual among academic disciplines in that we write full papers for conferences, and give conference papers almost as much weight as journal articles. But this structure evolved to make the contents of papers easier to understand, so it is just as applicable to conference papers as it is to journal articles. The difference is that conference papers are mostly preliminary work, and are shorter, whereas journal articles are longer and report more complete work.

Firstly, the abstract. This is not just a slapped-on piece of text that kinda-sorta says what you did. The abstract is where you summarise the entire paper: what you did, why you did it, what you found. The abstract is the hook by which you draw the reader into your paper, so a bad abstract means people won't read (and cite!) your paper later on.

The introduction sets the scene for your paper: this is where you survey the relevant literature (including all of the introduction stuffing that seems to account for about half of most people's citation count), establish what the problem is, establish what has already been done, and say what you are going to do. If you have any hypotheses or research questions, this is where you lay them out. And every paper should be investigating some hypothesis or research question, even if you don't explicitly state it. The last part of the introduction is where you are setting out for your reader exactly what it is you are trying to achieve in your paper: the earlier parts of the introduction are where you set out why you're doing it.

The methods is where you describe what you did. If you are describing a new technique or algorithm, describe it here, then describe how you evaluated it. If you are using computational intelligence to approach a real-world problem, then describe how you did this. The methods should have enough detail that someone could replicate your work, if they had access to the same data as you did. Don't needlessly repeat well-known algorithms here: I'm quite sick of reviewing conference papers that describe a simple genetic algorithm in their methods section. I know how a simple genetic algorithm works, and so does 99% of the people who are likely to read that paper. If it's well-established, just say which algorithm you used and reference it, that's what references are for.

In the results section you report your results. Since this is a conference paper, you need to focus on the key results. Don't fill half a page or more with a table of numbers! Especially don't give your tables of results captions like "Table of results" - most of your audience will have at least a functional level of reading comprehension, and therefore will already know that they're results. The caption of a table should describe the contents of the table, especially what each column / row heading means, and what the numbers represent. Captions are supposed to be independent of the text, that is,a reader should be able to understand the contents of the table without having to read the entire paper. A large collection of numbers is hard to understand, so in a conference paper it is often better to use a graphical representation of the results than a table. The text of the results describe the results but does not interpret them, so results sections can be quite short. You can describe any analyses of results you did in the results section, but that should probably be left to the discussion.

The discussion in many ways mirrors the introduction, because you are interpreting your results in the context of the literature you cited in the introduction. You are also answering your research questions, identifying any potential shortcomings in your approach, and suggesting future lines of research.In other words, the discussion is where you bring together all of the other sections of your paper. A well-written discussion eliminates the need for a conclusion.

Write succinctly, don't spend a lot of time saying something that can be explained by a reference. When I started writing conference papers in the mid-late 90s, they were limited to four-six pages because conference proceedings were all on paper. Now, conference proceedings are on DVD the page limits tend to be longer, closer to eight pages. But this is the limit, not the recommended number of pages. It's like the speed limit on the roads, the speed limit is the fastest you are allowed to drive, not the minimum speed you should be driving at all times. Just as you adjust your driving speed to the conditions, you should adjust the length of your paper to the material you are presenting: it is better to produce a succinctly-written, clear and to-the-point four page conference paper than it is produce an eight page paper that covers the same work but buries the important points among pages of padding.

Every sentence in a conference papers needs to tell a story, if a sentence doesn't contribute something to the paper, take it out. Avoid common grammatical errors, and don't rely on a spell-checker. Spell-checkers only tell you if a word is incorrectly spelt, it doesn't tell you if it is the wrong word for that sentence (I've seen  quite enough instances of a "pubic announcement", which sounds far ruder than what I assume they meant, which was a "public announcement"). Proof-read the paper at least twice, and if English is not your first language, for goodness sake get a native English speaker to read it. English grammar is bad enough for us native speakers, it has so many traps in it (especially with things like past / present / future tense) that errors are almost inevitable. Grammatical errors jar the reader out of the flow of the work, and if that happens often enough they will lose the thread of the paper and not understand what you are trying to communicate.

Researchers in computational intelligence can do good research, and are able to write good software. There is no reason they should not be able to write good conference papers.