Cognitive Computing A research blog by Ashwin Ram, PhD

Many students present a paper, especially one authored by someone else, by talking through it section by section or page by page. The student reads out the definitions and points the audience to the figures. Anything in italics is read out. The student works through the paper linearly, taking great care not to miss anything that the author might have written that might possibly be relevant. This approach is not useful because all that is happening is that the student is reading the paper aloud, forgetting that the audience is perfectly capable of reading the paper themselves and in most cases has already done so. Here is a different approach.

If you’re presenting the paper:

• Read the paper ahead of time, and decide what you think of the ideas presented in the paper. In particular, decide whether you think the paper has some good ideas or whether it belongs in the recycling bin. Keep in mind that very few papers have no worthwhile ideas whatsoever; however, if you’re convinced that your paper belongs in this category, follow the steps listed below for critiquing a paper.
• Next, decide which idea is the best idea (or a small cluster of related ideas) in the paper. “Best” may mean most novel, most central, most relevant, most clever, most important, and so on. Write down this idea, preferably in your own words, and a one-line justification for why this idea is the best one. (This step is particularly important when the paper you’re presenting is your own.)
• Now comes the crucial step: Figure out how to get your audience as quickly as possible to the point where they can understand this idea.
• Next, if necessary, elaborate the idea and fill in the details. Explain things like how the idea came about, how it was fleshed out in the paper, how it was proven, what benefit it had, what difference did it make, what alternative ideas might have been pursued instead, and so on.

If you’re critiquing the paper:

• Read the paper ahead of time, and decide what you think of the ideas presented in the paper.
• Next, determine what you think is the central fallacy or bad idea (or a small cluster of related ideas) in the paper. Don’t pick something tangential; you want a novel, central, relevant, clever, important idea (similar to the kind of idea you’d pick if you were presenting the paper) but one that is, in your mind, simply wrong. Write down this idea, preferably in your own words, and a short “bottom line” reason explaining why this idea is wrong.
• Now comes the crucial step: Figure out how to get your audience as quickly as possible to the point where they can understand the fallacy or bad idea.
• Next, if necessary, elaborate the idea and fill in the details. Explain things like how the idea came about, how it was fleshed out in the paper, what problems did it raise, why the proof was inadequate, what alternative ideas might have been pursued instead, and so on.

Date: 28 Jan 86 06:22:59 EST (Tue)
From: ram@yale-ring
Subject: Of growing code and diminishing hacks...
Sender: ram%yale-ring%arpa.yale@edu.mit.lcs.mc
To: t-discussion@arpa.yale, scheme@arpa.mit-mc

This is a tale of a sorry quest
To master pure code at the T guru’s behest
I enrolled in a class that appealing did seem
For it promised to teach fine things like T3 and Scheme

The first day went fine; we learned of cells
And symbols and lists and functions as well
Lisp I had mastered and excited was I
For to master T3 my hackstincts did cry

I sailed through the first week with no problems at all
And I even said “closure” instead of “function call”
Then said the master that ready were we
To start real hacking instead of simple theory

Will you, said he, write me a function please
That in lists would associate values with keys
I went home and turned on my trusty Apollo
And wrote a function whose definition follows:

    (cdr (assq key a-list))

A one-liner I thought, fool that I was
Just two simple calls without a COND clause
But when I tried this function to run
CDR didn’t think that NIL was much fun

So I tried again like the good King of yore
And of code I easily generated some more:

    (cond ((assq key a-list) => cdr))

It got longer but purer, and it wasn’t too bad
But then COND ran out and that was quite sad

Well, that isn’t hard to fix, I was told
Just write some more code, my son, be bold
Being young, not even a moment did I pause
I stifled my instincts and added a clause

    (cond ((assq key a-list) => cdr)
          (else nil))

Sometimes this worked and sometimes it broke
I debugged and prayed and even had a stroke
Many a guru tried valiantly to help
But undefined datums their efforts did squelch.

I returneth once more to the great sage of T
For no way out of the dilemma I could see
He said it was easy — more lines must I fill
with code, for FALSE was no longer NIL.

    (let ((val (assq key a-list)))
       (cond (val (cdr val))
             (else nil)))

You’d think by now I might be nearing the end
Of my ballad which seems bad things to portend
You’d think that we could all go home scot-free
But COND eschewed VAL; it wanted #T

So I went back to the master and appealed once again
I said, pardon me, but now I’m really insane
He said, no you’re not really going out of your head
Instead of just VAL, you must use NOT NULL instead

    (let ((val (assq key a-list)))
       (cond ((not (null? val)) (cdr val))
             (else nil)))

My song is over and I’m going home to bed
With this ineffable feeling that I’ve been misled
And just in case my point you have missed
Somehow I preferred (cdr (assq key a-list))

Here’s my latest geek poem: cognitivecomputing.wordpress.com/2010/10/11/a-is-for-apple—the-new-millennial-edition/