• Created by Unknown User (eeghenri) on 10.10.2014

Intro

  • Just a quick thing, 'cause it's easy stuff
  • Papers:
    • You find many
    • You ditch many
    • You read some
Contents
  • You read
    • (0. Title)
    • 1. Abstract
      • Not an introduction
      • A sales pitch
      • "You paper condensed into... whatever the length is"
      • WHat are we doing, why, what's the result, and are we happy about it?
        • If it doesn't contain this, it's crap.
        • Lots of CS abstracts are crap. Don't make it crap.
      • If the abstract is crap, the paper is crap.
      • If everything is fine, what to read next?
    • 2. Conclusion
      • CS people are crap at conclusions
      • A proper conclusion
        • We explored this intricate problem
        • We solved it with [fantastic algorithm]
        • Results were awesome
        • Btw, only works when [conditions]
      • (The discussion is usually somewhere in the conclusion)
    • 3. Result
      • Tells us the exact results. Tells us the cool numbers, the proof, stuff.
    • 4. Method
      • The methods. Did they do it properly, or were they just lucky?
    • 5. Design/implementation/(?)
      • We read about the thing, now we find out what the thing is.
    • 6. Reference list
      • A lot of info in the ref. list.
      • Note: If he knows of the work of the person, he might not read it, but if he doesn't know who the person, he'll read it.
      • If it's short, it's suspicious
        • Anything less than 2 pages is short.
        • If half of it is ref. to themselves, something's wrong.
      • Keith: Journals: a few pages. Conference papers: maybe only 5-10 sources listed, 'cause they'll have to compress it.
      • If you know the area, you'll know if they've covered the relevant literature
    • 7. Introduction / B&M (background and motivation)
      • Once you know it's a good paper, you read this stuff.
  • About this
    • It's a way of sorting the papers.
    • If you have 200 different papers on the subject, you want to fish out the good ones efficiently.
    • You use each step to check if you want to continue to the next step instead of ditching the paper.
  • Keith
    • Some people don't really write conclusions properly
      • They just review what they've done quickly
    • Then you might find what you're looking for in the discussion
    • But if you have to dig too much to find it, it's probably a bad paper
    • Sometimes he gets 50 pages, with 2 a paragraph-conclusion
      • The text on what it all means shouldn't be that skinny.
    • +
      • But for conferences, they might have to keep it very short.
  • +
    • Papers telling you what they'll tell you, several times, -> meh.
      • A bit is nice, but not too much
    • You might not have to understand every equation, etc. Skip some, find the stuff you need.
  • When he reads your thesis:
    • Any decent student can write a nice implementation, etc
    • The conclusion (w/discussion)   (aka "reflection")
      • -> THIS is what separates the good from the decent
    • You need to take a step back, look at the work, and write what it means.
  • Keith
    • Often: feedback: a few notes here and there, and 2 pages of comments on the abstract.
    • You don't put the punchline at the end. Don't save important stuff for the end. Put it in the abstract.
  • +
    • Keith will tell us how to write a paper later this year.
    • Last thing to write: the abstract.
  • Qs
    • Literature search
      • If you have to review some papers before you start,
        they might not appear in your searches. How to ref. them?
      • A:
        • 2 parts of the work
          • B&M
            • This chapter tells how you ended up at (below)
            • Your motivation for doing the work
            • Also motivate the reader to read
            • Worth investigating, etc, blabla
            • Before the experiment, you frame the experiment
            • Say, hey, robots are difficult, because of this and that, we want this and that, etc
              • More loose form
              • You can put that stuff here
          • Literature
            • A corpus of literature you build your work upon
            • How you write your program, what robots you use, etc, all comes from this literature
        • Keith:
          • "this is the hard part, this is why, [ref. to the other people], etc"
            • Shows it's not just something you dreamed up
            • You show that people would actually care
              • By showing with literature that people would care
              • Literature shows where the holes are
                • Filling the holes is your motivation
  • Next week is TBD
    • Om folk har idéer, ta kontakt
    • But let's meet anyway. Bring your lunch.
  • .
  • No labels