Як говорити про теорію

Я усвідомлюю, що це може бути спірним питанням, але це здавалося правильним місцем для запитання. Будь ласка, переадресуйте мене, якщо ні.

Фон полягає в тому, що я "практик" (докторант, я не вивчаю теорію CS), але в мене є розумне підґрунтя в алгоритмах і математиці студентів. Тим не менш, дискусії з теоретиками, як правило, дуже поверхневі, наче вони бояться використовувати зі мною математичні терміни, якщо я злякаюся. Насправді мені ідеально подобається і цікавиться теорією, але я просто не звик обговорювати це, тому, мабуть, не завжди використовую терміни, які б позначили мене як "теоретика". Я вважаю, що прямий підхід ("будь ласка, розкажіть мені деталі") не завжди працює, особливо якщо розглянутий теоретик прийняв поблажливий тон, який встановлює високу планку для експертизи (це трапляється часто).

Як теоретики, якщо ви фільтруєте людей таким чином, чи є у вас рекомендації, як практикуючий персонал може уникнути того, щоб ваш фільтр був "позначений"?

Ви можете працювати з грубими елітистами, але від мого досвіду, неохоче пояснювати технічні деталі залежить більше від контексту, ніж від людини, з якою я розмовляю. Зазвичай я уникав би давати технічні деталі доказу / алгоритму під час обіду або в коридорі, навіть якщо моїм співрозмовником був сам Алан Тьюрінг. Причина полягає в тому, що деталі значною мірою залежать від вибору позначень та від рукотворних концепцій, запроваджених для вирівнювання претензії. Крім того, оскільки всі розуміють речі по-різному і у мене немає загального способу пояснення поняття, мені завжди доводиться пристосовуватися до свого співрозмовника (саме тому надати технічні деталі в презентаційній роботі так важко до речі).

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

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

У моїй вже занадто довгій історії є кілька моралей:

• Не знецінюйте себе, тому що ви активно не працюєте в теоретичній інформатиці. Більшість людей не піклується про ваш чіткий досвід, поки ви покажете, що вам цікаво їх роботи.
• Коли люди розпливаються щодо доказу / концепції, будьте напоготові і намагайтеся вести розмову, задаючи точне запитання, яке показує ваше розуміння і тим самим допомагаєте співрозмовнику вибрати, яку частину доказу він повинен розвинути першим. Це, очевидно, досить важко і непередбачувано, тому що ви, можливо, не зможете давати відповідні коментарі на ходу (це трапляється з усіма навіть "теоретикам"), але якщо вам це вдасться, то, швидше за все, ви закінчитеся дуже просвічуючою дискусією.
• Навіть "теоретикам" потрібен час, щоб перезавантажити деталі доказу в голові, перш ніж змогли чітко пояснити це. Запишіть зустріч , чітко запитавши, що вас цікавлять технічні деталі X. Це дасть час вашому співрозмовнику та вам підготуватися, і полегшить дискусію. Під час обговорення обов'язково знайдіть білу дошку або аркуш паперу, щоб ви могли дійсно вникати в деталі.

Виступаючи як теоретик, який час від часу співпрацює з дослідниками систем, математичні деталі, як правило, є останнім, про що я хочу поговорити!

Оформити неправильну річ дуже легко, а крім того, що це велика марнотрата часу, це насправді дистифікує. Математика - це голка, а не молоток, і кожен укол голки дуже дорогий. Якщо я розмовляю з системним дослідником про перспективну співпрацю, перш ніж потрапити на будь-яку високоцерковну математичну церемонію, я хочу знати:

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

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

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

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

Мені дуже сподобалась відповідь Ніла, і це надихнуло мене поділитися частиною свого досвіду як теоретика, періодично співпрацюючи з більш прикладними людьми. Одним із найскладніших та найстрашніших етапів співпраці є пошук спільної мови - щоб проблему можна було формалізувати правильно. З мого досвіду, коли ставиться перед проблемою теоретик вирішити проблему, люди, як правило, дають занадто багато невідповідних деталей. Наприклад, якщо ми намагаємось передбачити часовий ряд, чи дійсно потрібно витратити 5 хвилин, сказавши мені, що ці фінансові операції підпадають під дію таких і таких норм, які ви хочете використовувати таким чином?

Моя конкретна пропозиція щодо розмови з теоретиками: Спробуйте зняти всі непотрібні деталі. Якщо ви намагаєтесь оптимізувати маршрут доставки, поговоріть про пункти та відстані (на відміну від того, щоб повідомити мені конкретні адреси). Говорячи про дані , скажіть відразу, що це за її тип: рядки, числові вектори, зображення (у якому форматі?). Це маркується чи не маркується? Якщо перший, який "тип" етикетки (двійкові, багатокласові, багатозначні, текстові анотації, реальні значення)?

$d$