Original: http://cs.stanford.edu/people/widom/paper-writing.html

 

Дженніфер Уідом, січень 2006 р.

 

---

Ось замітки з презентації, яку я проводила в п’ятницю під час ланчу, організованого лабораторією Stanford InfoLab 27 січня 2006 року, з кількома (небагатьма) правками під час мого виступу 4 грудня 2009 року, без переглядів нової версії 19 жовтня 2012 року. Презентація охоплює такі питання:

• Заголовок документа
• Анотація
• Вступ
• Пов’язана робота
• Основна частина
• Практичні експерименти
• Висновки
• Майбутня робота
• Подяка
• Цитування
• Додатки
• Граматика та дрібні питання презентації
• Механіка
• Версії та розповсюдження

---

Робочий приклад

Як робочий (вигаданий!) приклад припустимо, що ви створили і проводите експерименти з новим алгоритмом для зовнішнього багатопрохідної злиття-роду. Ваш алгоритм зменшує складність від O(n log n) до O(n), виходячи з припущення, що це прийнятно мати деяку обмежену “плутанину” в результаті. Ви плануєте писати результати для подання на великій конференції.

Примітка: цей приклад був використаний протягом всього живого уявлення, але я не стежив через багато в цих примітках. Таким чином, ноти включають в себе кілька вправ для читача.

 Заголовок документа

Заголовки можуть бути довгі й описові:

• Зовнішнє багатошарове сортування з гарантіями апроксимації в лінійному часі
  

або короткі й милі:

• Приблизне зовнішнє сортування
  

Ось середньої довжини мила назва, яка залишається у свідомості людей:

• Floosh: алгоритм у лінійному часі для приблизного зовнішнього сортування

Анотація

Поставити завдання, свій підхід і рішення, а основний внесок паперу. Увімкніть мало, якщо який-небудь фон і мотивація. Фактологічний, але вичерпним. Матеріал в анотації не повинні повторюватися пізніше слово в слово в документі.

(Вправа: написати реферат для багатопозиційного прикладу сортування.)

Вступ

Вступ принципово важливий. На той час, як суддя закінчив вступ, він, імовірно, зробив початкове рішення про те, чи слід прийняти або відхилити документ – він буде читати інші папери в пошуках доказів, щоб підтримати його рішення. Випадковий читач буде продовжувати, якщо уявлення полонила його, і поставлю папір в сторону інакше. Знову ж таки, вступ надзвичайно важливий.

Ось запатентована п’ятиступенева структура вступу лабораторії Stanford InfoLab. Якщо немає хороший аргумент проти цього, введення повинно складатися з п’яти пунктів, які відповідають таким п’ять питань:

1. У чому полягає суть питання?
2. Чому воно цікаве та важливе?
3. У чому його складність? (наприклад, чому прості рішення не спрацьовують?)
4. Чому його не вирішено раніше? (Або в чому проблема з раніше запропонованими рішеннями? Чим моє відрізняється?)
5. Які основні компоненти мого підходу та результатів? Також додайте всі можливі обмеження.

(Вправа: дайте відповідь на ці запитання про приклад багатопозиційного сортування.)

Тоді є останній абзац або підрозділ: “Резюме внесків”. Він повинен перерахувати основні внески у вигляді кулі, згадуючи, в яких ділянки вони можуть бути знайдені. Цей матеріал подвоюється як контур решти паперу, економлячи простір і усуваючи надмірність.

(Вправа: написати нумерований список для прикладу багатопозиційного сортування.)

 Пов’язана робота

Одвічне питання: чи повинна відповідна робота бути покриті поблизу початку паперу або ближче до кінця?

• Початок, якщо він може бути досить коротким, поки детально, або якщо це важливо, щоб зайняти міцну оборонну позицію про попередню роботу відразу ж. У цьому випадку робота, пов’язана з може бути або підрозділ в кінці введення, або його власний розділ 2.
• Кінець, якщо його можна підсумувати швидко на ранніх стадіях (у вступі або попередніх роботах), або при наявності достатніх порівняння вимагають технічного змісту документа. У цьому випадку пов’язана робота повинна з’явитися незадовго до висновків, можливо, у більш загальному розділі “Обговорення і пов’язана з ними робота”.

Основна частина

Вказівка №1: чіткий новий важливий технічний внесок повинен бути озвученої часу читач закінчується на сторінці 3 (тобто, чверть шляху через папір).

Вказівка №2: кожен розділ документа повинен розповісти історію. (Не треба, однак, потрапляють в загальну пастку розповідати всю історію про те, як ви прийшли на ваші результати. Просто розповісти про самих результатах.) Історія повинна бути лінійної, тримаючи читача займатися на кожному кроці і дивлячись вперед до наступного кроку. Там не повинно бути будь-яких істотних перерв – ті можуть піти в додатку; див. нижче.
Крім цих основних принципів, які застосовні до кожної папері, структура тіла сильно варіює залежно від змісту. Важливими компонентами є:

• Робочий приклад: коли це можливо, використовувати працюючий приклад протягом усієї роботи. Його можна вводити у вигляді підрозділу в кінці введення, або його власний розділ 2 або 3 (залежно від видів діяльності, пов’язаної).
• Попередні відомості: у цьому розділі, який слідує за введення і, можливо, пов’язаних з трудовою діяльністю і/або запускають Наприклад, встановлює позначення та термінологію, яка не є частиною технічного вкладу. Однією з важливих функцій цього розділу є окреслити матеріал, який не є оригінальним, але необхідно для паперу. Будьте короткими — пам’ятайте про вказівки №1.
• Зміст: основна частина роботи включає в себе алгоритми, опис системи, нові мовні конструкції, аналіз і т.д. По можливості використовувати “зверху вниз”. Опис: читачі повинні бути в змозі побачити, де матеріал збирається, і вони повинні бути в змозі пропустити вперед і до сих пір отримати цю ідею.

Практичні експерименти

Ми могли б цілий трактат на цю тему в спокої, і я, звичайно, не експерт. Ось деякі випадкові думки:

• На багатьох форумах адміністратори чекають експериментів.
• Це легко зробити “фальшивий” або безглузді експерименти, і багато робіт роблять.
• Легко ремісничих експериментів, щоб показати свою роботу в кращому світлі, і більшість робіт робити.
• Які експерименти продуктивності повинні вимірювати? Можливості:
  • Чистий час виконання
  • Чутливість до важливих параметрів
  • Масштабованість в різних аспектах: розмір даних, складність проблеми,…
  • Інше?
• Що практичні експерименти повинні показати? Можливості:
  • Абсолютна продуктивність (тобто прийнятність/корисність)
  • Відносна продуктивність при простих підходах
  • Відносна продуктивність при попередніх підходах
  • Відносна продуктивність при різних запропонованих підходах
  • Інше?

Висновки

Загалом короткий узагальнюючий абзац буде робити, і ні в якому разі не слід абзац просто повторити матеріал з реферату або Введення. У деяких випадках це можна зробити прямо зараз початкові претензії більш конкретним, наприклад, з посиланням на кількісні результати.

Майбутня робота

Цей матеріал має важливе значення – частина вартості паперу показує, яким чином робота встановлює нові наукові напрямки. Мені подобається марковані списки тут. (Насправді я люблю їх взагалі.) Кілька речей, щоб мати на увазі:

• Якщо ви активно бере участь в подальшій роботі, так би мовити. Т.д.: “Ми в даний час розширення алгоритм… бла-бла, і попередні результати обнадіюють”. Ця заява є для позначення вашої території.
• З іншого боку, слід пам’ятати, що деякі дослідники дивляться на розділи майбутньої роботи для дослідних тем. Моя думка така, що немає нічого поганого в тому, що – вважаю це компліментом.

Подяка

Не забувайте їх або ви будете мати людей з труднощами почуттями. Визнайте нікого, хто брав участь будь-яким чином: шляхом обговорення, зворотний зв’язок по проектам, реалізація і т.д. У разі сумнівів щодо того, щоб включити когось, включіть їх.

Цитування

Проведіть зусилля, щоб зробити все цитати повної і послідовної. Не просто скопіювати випадкове суперечливе BibTeX (або інших) записів з Інтернету і назвати його в день. Перевірте більше остаточний список літератури ретельно і переконайтеся, що кожен запис виглядає правильно.

Додатки

Додатки повинні містити докладні докази і тільки алгоритми. Додатки можуть мати вирішальне значення для overlength робіт, але як і раніше корисні в іншому випадку. Подумайте про додатки, як обгрунтування довільного доступу базових закривавлені деталі. Як правило:

• Додатки не повинні містити будь-яких матеріалів, необхідних для розуміння вкладу паперу.
• Додатки повинні містити всі матеріали, що більшість читачів не було б цікаво.

Граматика та дрібні питання презентації

Узагалі для написання статей настійно рекомендується прочитати коротку і дуже корисну працю Странка й Уайта Елементи стилю. Ось випадковий список улюблених мозолів.

• Так само, як програми, все “змінні” (термінологія і позначення) в документі повинні бути визначені перед використанням, а також повинен бути визначений тільки один раз. (Виняток: Іноді після довгої перерви корисно нагадати читачеві визначення.) Глобальні визначення повинні бути згруповані в секції прелімінаріі; інші визначення слід безпосередньо перед їх першим використанням.
• Не використовуйте “тощо”, якщо елементи, які залишилися, не є цілком очевидними.
  • Прийнятно: Ми пронумеруємо фази 1, 3, 5, 7 тощо.
  • Неприйнятно: Ми вимірюємо фактори продуктивності, такі як волатильність, масштабованість тощо.

  (Вправа: зазначене правило порушується хоча б один раз у цьому документі. Знайти порушення.)

• Ніколи не кажіть “із різних причин”. (Наприклад: Ми вирішили не розглядати альтернативу з різних причин.) Назвіть читачеві причини!
• Уникайте непов’язаного вживання “цей”, “той”, “ці”, “це” тощо (болюче місце Ульмана). Вимагаючи чіткого визначення того, що “це” відноситься до нав’язує ясність листи. Ось типовий приклад непов’язаного “цей”: Наші експерименти протестовані в кількох різних середовищах, і алгоритм добре працює в деяких, але не у всіх із них. Це важливо, тому що…(Вправа: зазначене правило порушується хоча б один раз у цьому документі. Знайти порушення.)
• Курсив для визначень або цитати, а не для акценту (болюче місце Гріса). Ваш лист має бути виконано таким чином, що контекст поодинці забезпечує достатню увагу.
  (Вправа: зазначене правило порушується хоча б один раз у цьому документі. Знайти порушення.)
• Люди часто неправильно використовують “котрий” проти “той”. “Той” указує; “котрий” не вказує. Приклади правильного вживання:
  • Усі алгоритми, які легко реалізувати, працюють у лінійному часі.
  • Усі алгоритми, котрі легко реалізувати, працюють у лінійному часі.

Механіка

• Завжди виконувати перевірку орфографії на вашому остаточному документі, без винятків.
• Для проектів і технічних звітів використовують шрифт 11, щедрі інтервали, поля 1″ і формат одного стовпчика. Там немає необхідності мучити ваших випадкових читачів крихітними шрифтами і щільною відстанню між використовуваними в матеріалах конференції в ці дні.
• У проектах і остаточних готових до друку, шрифти в цифрах повинна бути приблизно такий же розмір шрифту, який використовується для тексту в тілі документа.
• Таблиці, малюнки, графіки і алгоритми завжди повинні бути розміщені на верхній частині сторінки або колонки, а не в тексті, якщо вона не дуже мала і поміщається в потік паперу.
• Кожна таблиця, малюнок, графіка, або алгоритм повинен з’явитися на тій же сторінці, його першого заслання, або на наступній сторінці (готовий текстовий документ…).
• До остаточного уявлення або публікації вашої роботи, роздрукувати його один раз і подивіться – ви можете бути дуже здивовані, як різні вона виглядає на папері, від того, як це виглядало на екрані (якщо ви навіть набридло дивитися на це після того, як ви запускали текстовий документ останнього разу…).

Версії та розповсюдження

• У багатьох роботах є представлені (і пізніше опубліковано) конференції версія, поряд з “повною” паперу технічного звіту в Інтернеті. Важливо ретельно керувати версіями, як за змістом, і проліферації. Моя рекомендація, коли це можливо, для повної версії документа складається з просто версія конференції плюс додатки. Повний документ повинен бути єдиним публічний стороні від конференцій, вона повинна бути узгоджена з останньої (заключної) конференц-версії і модифікації в повній паперу завжди повинні переписати всі загальнодоступні попередні версії цього.
• Я вірю в покласти документи в Інтернеті в ту ж хвилину вони закінчили. Вони повинні бути датовані і можна посилатися як технічні звіти – це не обов’язково мати фактичний номер технічного звіту. Ніколи, ніколи не миритися папір з конференції повідомлення про авторське право, коли він тільки був представлений, і ніколи, ніколи не посилається на документ як “представлений на конференції X.” Ви просите тільки збентеженням, коли папір, нарешті, опубліковані в конференції Y через рік або два.