Scientific Communication

A rough framework for writing a generic paper (i.e. not for e.g. a review paper) from Eamon Keogh's How to do good research.

• Make a working title.
• Introduce the topic and define (informally for now) terminology.
• Introduce the motivation - explain why the topic is important.
• Relate to current literature.
• Mention the gap and what needs to be done.
• Introduce research question formally.
• Introduce necessary background material.
• Introduce formal definitions.
• Introduce methods being proposed.
• Describe experimental setup, and what the experiments aim to show.
• Describe the data used in the experiments.
• Summarize the results with figures/tables.
• Discuss the results.
• Explain any conflicting results, unexpected findings and/or conflicts with other research.
• Describe the limitations.
• Describe the importance of the findings.
• Mention possible directions for further research.
• Acknowledges and references.

One important principle: Do not make the reviewer of your paper think.

Quintilian's quote: "We should not speak so that it is possible for the audience to understand us, but so that it is impossible for them to misunderstand us" - practically this means always eliminate any possibility of ambiguity.

First impressions are important - a good introduction with a good motivation is half your success. The first page should answer the following questions:

• What is the problem?
• Why is it interesting and important?
• Why is it hard, and why do naive approaches fail?
• Why hasn't it been solved before? Or what is missing is the previous proposed solutions?
• What are the key components being proposed?

Directly quote other papers if suitable.

Read back-to-front paragraph by paragraph when editing your own work.

Science-backed tips for writing.

See this document.

• Look into datavizproject for ideas on figures, and this Twitter thread. Use plt.figure(dpi=300) instead of plt.figure(figsize=(8, 8)) to resize figures and text font size at the same time. Also plt.subplot_mosaic(...) (learnt from this Tweet). This online application generated graphviz plots online. Matplotlib cheatsheets are available here.
• Look into this blog post on using text in visualizations.
• See also the glumpy, vispy Python packages, Python&Open-GL.
• Altair-viz.

• Great examples include distill.pub, and whatever framework used here.

• speaking.io.

• Notes from David MacKay. Original source here.

   --------------------------------------------
  Advice on How to give a talk (for beginners)
  --------------------------------------------
  
  - with thanks to all the speakers, good and bad, from whom I have learned.
  
  A: Slide design
  ===============
  
  1. *** Use big fonts. Must be visible from back. Use thick fonts -
  thin lines are invisible from a distance. Never photocopy papers onto
  transparencies at 1:1 -- fonts in a paper are much too small for
  projection. If you do copy a paper onto a slide, add some colour to
  it.
  
  2. *** Don't put lots of stuff on one slide. Don't write out huge long
  sentences and then read them out to the audience. Write abbreviated
  sentences only.
  
  3. Use colours but only visible ones. (Not yellow on transparencies;
  not red-on-black or blue-on-black or vice versa on slides.) I like
  always using one colour for text, another for headings, a third for
  equations, or maybe two colours within equations if it makes them
  clearer. (eg black for = | and parentheses, and other colours for
  parameters and variables). Make a decision to use washable or
  non-washable pens. I recommend using washable ones until you have got
  very good at writing slides. Try thick and thin pens. I find my
  writing looks best with medium pens.
  
  B: Speaking
  ===========
  
  4. *** Stand to one side of the screen and use a pointer. Have a
  system for processing your transparencies - for example, turn them
  over like a book and keep blank sheets of paper between them. You
  should be able easily to go back and find previous slides.
  
  5. Plan every sentence that you are going to say. Use words with
  precision.
  
  6. Never talk to yourself or make quiet asides (such as mumbling
  "crumbs, that is a bad slide").
  
  7. When answering a question, repeat the question, then answer it.
  
  C: Content
  ==========
  
  8. *** Give a talk that is too low in level rather than too high;
  people much prefer to understand 90% of the talk than 10%. Just one
  new thing, with the rest all being review, is fine. People also like
  talks that finish ahead of time.
  
  Never imagine you are going to report all the work you have
  done. Don't say "I tried this; then I tried this; then I did
  this". Remember that you have worked on your project for months and it
  would take months to describe everything you have done.
  
  9. Say what you are going to say. Say it. Then say what you have
  said. An audience likes to be given a sense of direction. Is there a
  single key point you are going to address? Flag this prominently when
  it turns up. Is there a key question which you address? Pose it at the
  start of the talk.
  
  10. Don't go through mathematical derivations step by step. Just state
  assumptions and results (and be sure you can produce the derivations
  in outline or detail if asked).
  
  11. One good way to plan the talk and to write the paper is to explain
  the whole topic from beginning to end to a novice recipient.
  
  12. Stay cool and have fun.
  

#TODO

• This blog post has some tips.

Collection of rough ideas that can be helpful to motivate those with no exposure to technical details.

• The Konigsberg problem and Euler's solution are a great example of creative thinking in mathematics, and answering a question that is somewhat practical in the real world.
• Application of game theory to things like network routing, and statistics/information theory to not only break the Enigma code but to make sure they could make use of that information from the cracked codes without letting others know that the Enigma system is compromised.