Re: how to write good CS paper

On Thu, 24 May 2001 17:42:28 GMT, mikito Harakiri <nospam_at_newsranger.com> wrote:
>After struggling with yet another CS paper (clearly, I'm outsider;-), I'm trying
>to collect some recipies for writing a *readable* paper. Please share your ideas
>if you have some.

CS papers are traditionally poorly written, full of false rigor and unnecessarily complex terminology.

>One spot that I noticed is indexing. It seems like researcher's tools for
>enumeration are extremely limited, so they use indexing everywhere. So we easily
>get tensor notation in a subject area which is quite simple otherwise. Example:
>
>> 2. NOTATIONS
>> Finite Structures and Logics. All structures are assumed to be finite.
>> A relational signature 'sigma' is a set of relation symbols
>> {R_1 , ..., R_l}, with associated arities p_i > 0.

Well, I guess you have to say something. This is pretty much traditional mathematical notation used in many fields, so you might say they use it for familiarity.

>Here we have some number of relations and authors use subscripts to enumerate
>them within a set. I object! Those indexes would stick to the rest of the paper
>and every orthogonal enumeration, a need for which is discovered later in the
>game, would have to be added on top of it. If the results of the paper don't
>depend on join operations why not to use a single relation 'A' (or universal
>relation?). Now, if joining is coming somewhere into the picture, then why not
>introducing 2 relations only: A and B? The effects where joining 3 relations
>produces something new are subtle, so more than 2 relations aren't probably
>needed in every paper.

It's all because they want to make the point that in principle it doesn't matter if you have 2 or 3 or 99999 joins. Again, it's just traditional notation. Curious, what is your area, if you're an outsider in CS?

>Next comes enumeration of attributes within a relation. Advocates of excessive
>mathematical notation, again, would write something like P_i(a_1, ..., a_k)
>(keeping index from previois part, remember?-). Now, what advantages enumerating
>columns like this are? Are we going to use induction on the number of columns,
>or leverage ariphmetic properties of the subscript indexes somehow? Wouldn't
>results of the paper just be fine with relation EMP(name, salary), for example,
>even if some advanced results concerning complexity of queries are concerned?

Yes. Well, I suppose they could simply make their point on a finite, simple example, and then just say at the end, "oh, by the way, this works for any arities", but that would just be too easy. <g>

Joshua Stern
JRStern_at_gte.net Received on Sun Jul 22 2001 - 01:26:10 CEST