Когда полезна теоретическая информатика?
https://stackoverflow.com/questions/235394
-
04-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
На занятиях мы узнали о проблеме остановки, машинах Тьюринга, редукции и т. д.Многие одноклассники говорят, что это все абстрактные и бесполезные понятия, и знать их нет никакого смысла (т. е. их можно забыть после окончания курса и ничего не потерять).
Чем полезна теория?Вы когда-нибудь использовали его в своем повседневном программировании?
Решение
Когда я заканчивал колледж, я предполагал, что нахожусь на одном уровне со всеми:«У меня есть степень бакалавра в CS, как и много других людей, и мы все можем делать по сути одно и то же». В конце концов я обнаружил, что мое предположение было ложным.Я выделялся, и мое прошлое во многом повлияло на это, особенно моя степень.
Я знал, что была одна «небольшая» разница в том, что у меня была «BS» в CS, потому что мой колледж был одним из первых (предположительно № 2 в 1987 году) в стране, получившей аккредитацию за свою программу CS -получения, и я Окончил во втором классе, чтобы иметь эту аккредитацию.В то время я не думал, что это имеет большое значение.
В старших классах школы и колледже я также заметил, что особенно хорошо справляюсь с компьютерными науками — намного лучше, чем мои сверстники и даже лучше, чем многие из моих учителей.Меня часто просили о помощи, я занимался репетиторством, меня просили помочь с исследовательским проектом, и мне разрешили провести независимое исследование, когда больше никого не было.Я был рад, что смог помочь, но не особо задумывался о разнице.
После колледжа (США) я прослужил четыре года в ВВС, два из которых получал степень по CS.Там я заметил, что очень немногие из моих коллег имели высшее образование или даже подготовку, связанную с компьютерами.Военно-воздушные силы отправили меня на пятимесячную сертификационную подготовку, где я снова обнаружил отсутствие ученых степеней и подготовки.Но здесь я начал замечать разницу — стало совершенно очевидно, что многие из людей, с которыми я столкнулся, ДЕЙСТВИТЕЛЬНО не знали, что они делают, включая людей с образованием или ученой степенью.Позвольте мне, пожалуйста, проиллюстрировать.
В моей сертификационной подготовке ВВС приняли участие тринадцать человек (включая меня).Будучи офицерами ВВС или их эквивалентами, мы все имели степени бакалавра наук.Я был посередине по возрасту и званию (я был О-2 среди шести О-1 и шести О-3 и выше).По окончании этого обучения ВВС признали нас всех одинаково компетентными в приобретении, создании, проектировании, обслуживании и эксплуатации ЛЮБОГО компьютера или системы связи для ЛЮБОГО подразделения Министерства обороны.
Однако из тринадцати из нас только шестеро имели какую-либо степень, связанную с компьютером;остальные семь имели ученые степени от аэронавтики до химии/биологии и психологии.Я узнал, что из шести человек со степенью бакалавра наук двое никогда не писали никаких программ и никогда не пользовались компьютером разве что случайно (писали статьи, играли в игры и т. д.).Я узнал, что еще двое из нас написали ровно одну программу на одном компьютере во время обучения по программе бакалавриата.Только еще один человек и я написали более одной программы или использовали более одного типа компьютеров — действительно, мы обнаружили, что мы оба написали много программ и использовали разные типы компьютеров.
Ближе к концу нашего пятимесячного обучения нашему классу был поручен проект по программированию, и мы были разделены на четыре группы, чтобы выполнять его отдельно.Наши преподаватели разделили класс, чтобы справедливо распределить «таланты программирования», и распределили роли руководителя группы, технического руководителя и разработчика.Каждой группе была дана неделя на реализацию (на языке Ada) полноэкранного текстового пользовательского интерфейса (это был 1990 год) для авиасимулятора поверх библиотеки пилотажной механики, предоставленной инструктором.Меня назначили техническим руководителем моей команды из четырех человек.
Мой руководитель группы (у которого не было компьютерного образования) попросил остальных троих разделить проект на задачи, а затем поручил каждому из нас треть из них.Я выполнил свою треть задач к середине первого дня, а затем провел остаток дня, помогая двум другим товарищам по команде, разговаривая с руководителем моей команды (BSing ;^) и играя на своем компьютере.
На следующее утро (второй день) мой руководитель группы конфиденциально сообщил мне, что двое других наших товарищей по команде не добились прогресса (на самом деле невозможно написать оператор «если», который будет компилироваться), и попросил меня взять на себя их работу.Я закончил весь проект к полудню, а остаток дня моя команда провела, управляя симулятором.
Другой парень с аналогичным образованием в области информатики также был назначен техническим руководителем его команды, и они закончили работу к концу третьего дня.Они также начали летать на своем симуляторе.Две другие команды не закончили игру и даже не добились значительного прогресса к концу недели.Нам не разрешили помогать другим командам, поэтому всё и оставили.
Между тем, к середине третьего дня я заметил, что симулятор полета, похоже, вел себя «неправильно».Поскольку один из моих одноклассников имел высшее образование в области воздухоплавания, я спросил его об этом.Он был озадачен, а затем признался, что на самом деле не знает, что заставляет самолет летать!?!Я был ошеломлен!Оказывается, вся его учебная программа была посвящена вопросам безопасности и расследования авиакатастроф – никакой реальной математики или науки, лежащей в основе полетов.С другой стороны, я, возможно, имел небольшое образование в области аэронавтики (помните USAFA?), но мы сконструировали крылья и провели настоящие испытания в аэродинамической трубе.Поэтому остаток недели я спокойно провел, переписывая предоставленную инструктором библиотеку пилотажной механики, пока симулятор не полетел «правильно».
С тех пор я проработал почти два десятилетия в качестве подрядчика, а иногда и в качестве сотрудника, всегда занимаясь разработкой программного обеспечения и сопутствующей деятельностью (администратор баз данных, архитектор и т. д.).Я продолжал находить то же самое и в конце концов отказался от своих юношеских предположений.
Итак, что именно я обнаружил?Не все равны, и это нормально — я не лучший человек, потому что я умею эффективно программировать, но я более полезен, ЕСЛИ это то, что вам от меня нужно.Я узнал, что мое прошлое действительно имеет значение:Взросление в семье электриков и инженеров -электриков, строительство наборов электроники, чтения буквально каждой компьютерной книги в школе/публичных библиотеках, потому что у меня не было доступа к реальному компьютеру, а затем переехал в новый город, где у моей средней школы были компьютеры , затем получить свой компьютер в качестве подарка, ходя в школы, в которых были компьютеры разных размеров и видов (ПК на мэйнфреймы), получая аккредитованную степень из очень хорошей инженерной школы, необходимо писать много программ на разных языках на разных Виды компьютеров, необходимость писать жесткие программы (например, моя собственная виртуальная машина с пользовательским языком сборки, или реализация сжатия Хаффмана и т. Д.), Не устраняю для себя, создавая свои компьютеры из деталей и устанавливая все программное обеспечение и т. Д. Полем
В конечном итоге я понял, что мои способности основаны на знании того, как работают компьютеры, начиная с электрического уровня и выше: дискретные электронные компоненты, схемы, подсистемы, интерфейсы, протоколы, биты, байты, процессоры, устройства, драйверы, библиотеки, программы. , системы, сети, вплоть до огромных конгломератов корпоративного класса, над которыми я сейчас обычно работаю.Итак, когда эта чертова штука плохо себя ведет, я точно знаю, КАК и ПОЧЕМУ.И я знаю, что нельзя сделать, и то, что можно.И я знаю многое о том, что сделано, опробовано и что осталось относительно неисследованным.
Самое главное, что после того, как я все это узнал, я понял, что ни черта не знаю.Перед лицом всего того, что потенциально можно знать, мои знания ничтожны.
И меня это вполне устраивает.Но я рекомендую вам попробовать.
Другие советы
Правдивая история:
Когда я получил свою первую работу по программированию в аспирантуре, ребята, которые владели компанией, в которой я работал, были пилотами. Через несколько недель после того, как меня приняли на работу, один из них задал мне этот вопрос:
В Арканзасе 106 аэропортов. Не могли бы вы написать программу, которая бы найти кратчайший маршрут, необходимый для земля у каждого из них?
Я серьезно думал, что он проверяет меня на моих знаниях о проблеме коммивояжера и NP-полноте. Но оказывается, что он не был. Он ничего не знал об этом. Он действительно хотел программу, которая нашла бы самый короткий путь. Он был удивлен, когда я объяснил, что существует 106 факторных решений, и найти лучшее было хорошо известной вычислительно неразрешимой проблемой.
Так что это один пример.
Конечно, это полезно.
Представьте себе разработчика, работающего над механизмом шаблонов. Вы знаете такие вещи ...
Blah blah blah ${MyTemplateString} blah blah blah.
Все начинается просто, с нахальным маленьким регулярным выражением для выполнения замен.
Но постепенно шаблоны становятся немного более замысловатыми, и разработчик включает в себя функции для шаблонизации списков и карт строк. Для этого он пишет простую маленькую грамматику и генерирует парсер.
Будучи очень хитрым, движок шаблонов может в конечном итоге включить синтаксис для условной логики, чтобы отображать различные блоки текста в зависимости от значений аргументов.
Кто-то, обладающий теоретическим опытом в CS, признает, что язык шаблонов постепенно становится завершенным по Тьюрингу, и, возможно, шаблон Interpreter будет хорошим способом его реализации.
Создав интерпретатор для шаблонов, ученый-компьютерщик может заметить, что большинство шаблонных запросов являются дубликатами, генерирующими одни и те же результаты снова и снова. Таким образом, кэш разрабатывается, и все запросы передаются через кеш перед выполнением дорогостоящего преобразования.
Кроме того, некоторые шаблоны намного сложнее, чем другие, и для их рендеринга требуется гораздо больше времени. Может быть, у кого-то возникнет идея оценить исполнение каждого шаблона перед его рендерингом.
Но подожди !!! Кто-то из команды отмечает, что, если язык шаблонов действительно завершен по Тьюрингу, то задача оценки времени выполнения каждой операции рендеринга является примером проблемы остановки !! Yikes, не делай этого !!!
На практике теория заключается в том, что вся практика основана на теории. Теоретически.
Вещи, которые я использую чаще всего:
- вычислительная сложность для написания алгоритмов, которые изящно масштабируются
- понимание того, как работают распределение памяти, подкачка и кэширование ЦП, чтобы я мог писать эффективный код
- понимание структур данных
- понимание потоков, блокировок и связанных с ними проблем
Что касается машин Тьюринга и т. д.Я думаю, что это важно, потому что оно определяет ограничения, в которых мы все действуем.Это важно ценить.
это разница между обучением алгебре и обучением использованию калькулятора
если вы знаете алгебру, вы понимаете, что одна и та же проблема может проявляться в разных формах, и вы понимаете правила ее преобразования в более лаконичную форму
если вы знаете только, как пользоваться калькулятором, вы можете тратить много времени, нажимая кнопки на проблеме, которая либо (а) уже решена, (б) не может быть решена, либо (в) похожа на какую-то другую проблему (решено или не решено), которое вы не узнаете, потому что оно в другой форме
представь на мгновение, что информатика - это физика ... вопрос может показаться глупым?
Мой друг работает над языком с некоторыми шаблонами. Меня попросили сделать небольшую консультацию. Часть нашего обсуждения касалась возможности шаблонов, потому что, если бы шаблоны были выполнены по Тьюрингу, им пришлось бы действительно учитывать свойства VM-ish и то, как / если их компилятор будет их поддерживать.
Моя история на этот счет: теория автоматов все еще преподается, потому что она все еще имеет отношение. Проблема остановки по-прежнему существует и ограничивает ваши возможности.
Теперь, имеют ли эти вещи отношение к тому, что жокей базы данных разрабатывает код C #? Возможно нет. Но когда вы начнете переходить на более продвинутый уровень, вам захочется понять свои корни & Amp; фонды.
Хотя я не применяю их непосредственно в повседневной работе, я знаю, что мое образование в области формальной информатики повлияло на мой мыслительный процесс. Я определенно избегаю определенных ошибок с самого начала, потому что мне внушены уроки, извлеченные из формальных подходов.
Это может показаться бесполезным, пока они учатся; но держу пари, что у твоего одноклассника в конечном итоге возникнет проблема, заключающаяся в том, что он будет использовать то, чему его учили, или, по крайней мере, шаблоны мышления, стоящие за ним ...
Воск включен ... Воск выключен ... Воск включен ... Воск выключен ... В любом случае, какое это имеет отношение к каратэ?
На одной работе мне было поручено улучшить алгоритм трассировки сети нашей модели распределения электроэнергии, поскольку тот, который они использовали, был слишком медленным. Трехфазная сеть была, по сути, тремя n-деревьями (поскольку в электрических сетях петли не допускаются). Узлы сети находились в базе данных, и некоторые из первоначальной команды не могли понять, как построить модель в памяти, поэтому отслеживание выполнялось последовательными глубинными SELECT в базе данных с фильтрацией на каждом этапе. Таким образом, чтобы отследить узел для десяти узлов с подстанции, потребовалось бы как минимум 10 запросов к базе данных (первоначальные члены команды были вундеркиндами базы данных, но им не хватало приличного фона в алгоритмах).
Я написал решение, которое преобразовало 3 сети n-деревьев узлов из базы данных в структуру данных, где каждый узел хранился один раз в массиве структуры узлов, а отношение n-дерева было преобразовано в три двоичных дерева с использованием дважды связанные указатели внутри массива, чтобы можно было легко отслеживать сеть в любом направлении.
Это было как минимум на два порядка быстрее, три на очень длинных трассах вниз по течению.
Грустно было то, что мне пришлось практически преподавать класс по n-деревьям, двоичным деревьям, указателям и двусвязным спискам нескольким другим программистам, которые обучались базам данных и VB, чтобы они могли понять алгоритмы.
Это классическая дихотомия между «как» и «что».Ваши одноклассники изучают, «как» программировать программное обеспечение, и они очень сосредоточены на ближнем фокусе;с этой точки зрения, с точки зрения реализации, кажется, что знание таких вещей, как состояния остановки и машины Тьюринга, не имеет значения.
Однако «как» — это очень малая часть реальной работы, которую от вас ожидают в области информатики.Фактически, большинство успешных инженеров, которых я знаю, вероятно, оценили бы это менее чем в 20 процентов от фактической работы.«Что» делать, гораздо важнее;и для этого решающее значение имеют основы информатики.«Что» вы хотите сделать, в большей степени связано с дизайном, чем с реализацией;а хороший дизайн - это...ну, назовем это просто «нетривиальным».
«Есть два способа создания программного обеспечения:Один из способов — сделать его настолько простым, чтобы не было очевидных недостатков, а другой — сделать его настолько сложным, чтобы не было очевидных недостатков.Первый способ гораздо сложнее." - МАШИНА.Хоар
Удачи в учебе!
Я думаю, что понимание фундаментальных моделей вычислений полезно: уверен, что вам никогда не понадобится на практике преобразовывать машину Тьюринга в машину регистра, но вы узнаете, как увидеть, что две совершенно разные проблемы действительно являются примерами одной и той же концепции. является критическим навыком.
Большая часть знаний - это не " практический " ;, но он помогает вам соединять точки способами, которые вы не можете предвидеть, или дает вам более богатый словарный запас для описания более сложных идей.
Важны не конкретные проблемы, которые вы изучаете, а принципы, которые вы изучаете, изучая их. Я использую понятия об алгоритмах, структурах данных, языках программирования и операционных системах каждый день на своей работе. Если вы работаете программистом, вы все время будете принимать решения, которые влияют на производительность системы. Чтобы сделать правильный выбор, вам необходимо иметь прочную основу в фундаментальных абстрактных понятиях.
Если вы работаете в компании, которая делает новаторскую работу, важно иметь возможность сообщать архитекторам и разработчикам о преимуществах. Существует много шумихи по поводу всех видов технологий, и позиционирование себя может быть трудным. Когда вы формулируете свои инновации в научном и теоретическом плане, вы определенно получаете преимущество, и клиенты чувствуют, что вы - настоящая вещь. Я могу сказать людям: есть новый способ справиться с состоянием, кодированием и недетерминизмом (то есть сложностями), и вы определенно можете быть более продуктивными, чем сегодня.
Если вы посмотрите на свою карьеру в долгосрочной перспективе, изучение теории даст вам глубину, глубину, которую вам нужно развивать. Возврат инвестиций в изучение вашего 5-го или 6-го языка программирования будет намного меньше, чем изучение вашего 2-го и 3-го. Знакомство с теорией даст вам представление о реальной технике, о том, где находятся степени свободы и как вы можете сделать правильный компромисс.
Важные понятия 1) Государство, 2) Кодирование, 3) Недетерминизм. Если вы их не знаете, они вам не помогут. Теория должна предоставить вам общую картину и понимание того, как основные понятия сочетаются друг с другом. Это должно помочь вам отточить свою интуицию.
Пример: в некоторых из приведенных выше ответов упоминается проблема остановки и машины Тьюринга. Когда я наткнулся на статью Тьюринга в колледже, я совсем не чувствовал себя просветленным. Однажды я наткнулся на теорему Гёделя о неполноте и, в частности, нумерацию Гёделя. Вещи начали иметь много смысла. Спустя годы я прочитал о Георге Канторе в книжном магазине. Теперь я действительно начал понимать машины Тьюринга и проблему остановки. Попробуйте сами и посмотрите & Диагональный аргумент Кантора & Quot; в Википедии. Это одна из самых удивительных интеллектуальных вещей, с которыми вы когда-либо сталкивались.
Пища для размышления. Типичная машина Тьюринга - не единственный способ создания машины с переходом состояний. Машина Тьюринга с двумя, а не с одной лентой даст вам гораздо большую скорость для ряда алгоритмов. http://www.math.ucla.edu/~ynm/papers/ eng.ps
Вы можете лучше разобраться в этих идеях, чем я, прочитав эту книгу. Ссылка внизу этого поста. (По крайней мере, ознакомьтесь с оглавлением на Amazon, чтобы понять, о чем все это):
Я нашел книгу Розенберга сенсационной. http://www.amazon.com/The-Pillars-Computation-Theory-Nondeterminism/ dp / 0387096388 Если у вас есть только одна книга по теории, ИМХО, это должна быть одна.
После того, как я окончил CS, я подумал о том же: целая куча теорий, которые мы изучали, на практике совершенно бесполезны. Это оказалось правильным в течение короткого периода времени, однако в тот момент, когда вы решаете сложные задачи, теория, безусловно, более ЦЕННА, чем практика. каждый после нескольких лет программирования может написать несколько программ, которые " work " но не каждый способен понять как. Независимо от того, что большинство из нас будет иметь дело в определенный момент с проблемами производительности, задержками в сети, прецизионностью, масштабируемостью и т. д. На этом этапе теория имеет решающее значение. Для того чтобы разработать хорошее решение при работе со сложными системами, очень важно знать, как работает управление памятью, концепции процессов и потоков, как им назначается память, или эффективные структуры данных для производительности и так далее.
Однажды, например, я работал над проектом, включающим множество математических вычислений, и в какой-то момент наше программное обеспечение перестало работать. во время отладки я выяснил, что после некоторой математической операции я получил число как DOUBLE со значением 1.000000000002, но с математической точки зрения не может быть > 1, который на более позднем этапе программы давал легендарное исключение NaN . я потратил некоторое время, чтобы понять это, но если бы я уделил больше внимания " приближению Double and Float " урок я бы не потратил впустую это время.
Я не пользуюсь им ежедневно. Но это дало мне много понимания, которое помогает мне каждый день.
Я обнаружил, что все, что мне нужно для ежедневного блаженства в теоретическом мире CS, - это высказывание мантры & «Низкая связь и высокая сплоченность»! Роджер С. Прессман сделал это научным путем, прежде чем Стив Макконнелл сделал его модным.
Да, я обычно использую диаграммы состояний для разработки формы и последовательности программы. Как только теоретически это сработает, я начинаю кодировать и тестировать, проверяя состояния на ходу.
Я считаю, что они также являются полезным инструментом для объяснения поведения процесса другим людям.
Простой.Например:если я использую RSACryptoServiceProvider Я хотел бы знать, что это такое и почему я могу этому доверять.
Потому что шаблоны C ++ на самом деле являются своего рода лямбда-исчислением. См. Www.cs.nott.ac.uk/types06/slides/michelbrink_types_06.pdf
Я сейчас учусь на курсе по распределенным алгоритмам. Есть глава о отказоустойчивости, и она содержит некоторые доказательства на верхней границе того, сколько процессов может сбоить (или плохо себя вести), чтобы распределенный алгоритм мог обрабатывать его правильно.
Для многих проблем предел неправильного поведения процессов составляет до одной трети от общего числа процессов. Это очень полезно, на мой взгляд, потому что вы знаете, что бессмысленно пытаться разработать лучший алгоритм (при данных предположениях).
Даже если теоретические курсы не будут использоваться напрямую, это может помочь вам лучше думать о чем-то.
Вы не знаете, что ваш босс попросит вас сделать, возможно, вам придется использовать то, что, по вашему мнению, не принесет пользы, как сказал Джеффри Л. Уитледж.
Если честно, я как бы не согласен со многими ответами здесь. Я написал свой первый компилятор (для забавы; у меня действительно слишком много кофе / свободного времени), не пройдя курс по компиляторам; в основном я просто сканировал код для другого компилятора и следовал шаблону. Я мог бы написать синтаксический анализатор на C на макушке головы, но я не думаю, что смог бы вспомнить, как нарисовать автомат, если от этого зависела моя жизнь.
Когда я решил, что хочу сделать вывод типа в своем игрушечном (императивном) языке программирования, я сначала просмотрел, вероятно, пять статей, глядя на что-то под названием " типизированное лямбда-исчисление " собираешься что .... то .... **** ....? Сначала я пытался реализовать что-то с помощью & Quot; обобщенных переменных & Quot; и " неуниверсальные переменные " и понятия не имел, что происходит. Затем я все это пересмотрел и сел с блокнотом, выясняющим, как я могу реализовать его практически с поддержкой всего, что мне нужно (подтипирование, первоклассные функции, параметризованные типы и т. Д.), Подумав пару дней & усилитель; При написании тестовых программ я потратил больше недели, чтобы попытаться выяснить теоретическую чушь.
Знание основ вычислений (то есть, как работает виртуальная память, как работают файловые системы, потоки / планирование, SMP, структуры данных) оказались очень полезными. Теория сложности и вещи Big-O иногда оказывались полезными (особенно полезными для таких вещей, как проектирование СУБД). Проблема остановки и автомат / теория Тьюринга? Никогда.
Я знаю, что это старо, но мой короткий ответ тем, кто утверждает, что теория «бесполезна» и что они могут практиковать свою профессию без нее, таков:
Без базовой теории нет практики.
Почему теория полезна?
Теория - это фундамент, на котором строятся другие вещи. Когда теория применяется , результатом является практика.
Рассмотрим компьютеры сегодня. Обычный компьютер сегодня смоделирован и построен на основе машины Тьюринга, которая, для простоты, является абстрактной / теоретической моделью для вычислений. Эта теоретическая модель лежит в основе основы вычислений, и все вычислительные устройства, которые мы используем сегодня, от высокопроизводительных серверов до карманных телефонов, работают, потому что основа лежит в основе звука.
Рассмотрим анализ алгоритмов. Проще говоря, анализ алгоритмов и теория сложности времени использовались для классификации проблем (например, P, NP, EXP и т. д.), а также того, как ведут себя алгоритмы, которые мы имеем. при попытке решить разные проблемы в разных классах.
Предположим, что кто-то из ваших друзей устроился на работу в каком-то месте X, и в это время менеджер делает несколько простых запросов, таких как эти примеры:
Пример 1 . У нас большой парк транспортных средств для доставки, которые посещают разные города в нескольких штатах. Нам нужно вы внедрить систему, чтобы выяснить, какой кратчайший маршрут для каждого транспортного средства, и выбрать оптимальный из всех возможных. Вы можете сделать это?
Думая, что теория «бесполезна», ваши друзья не понимают, что им только что дали задачу коммивояжера (TSP), и приступают к разработке этой системы, не задумываясь, только чтобы обнаружить их наивную попытку проверить все возможности, как первоначально запрашивалось, настолько медленны, что их система непригодна для использования в любых практических целях.
На самом деле, они понятия не имеют, почему система работает с " приемлемым " Уровень при проверке 5 городов, но становится очень медленным в 10 городах и просто замирает при переходе только в 40 городов. Они полагают, что это только & Quot; в 2 и 8 раз больше городов, чем в 5 городских тестах & Quot; и удивляетесь, почему программа просто не требует " в 2 и 8 раз больше " соответственно ...
Понимание теории позволило бы им понять следующее, хотя бы с первого взгляда:
<Ол>Цифры говорят сами за себя:
+--------------+-------+-----------------------------------------------------------------+
| No. Cities | O(N!) | Possibilities |
+--------------+-------+-----------------------------------------------------------------+
| 5 | 5! | 120 |
| 10 | 10! | 3,628,800 |
| 40 | 40! | 815,915,283,247,897,734,345,611,269,596,115,894,272,000,000,000 | <-- GG
+--------------+-------+-----------------------------------------------------------------+
Они могли бы с самого начала понять, что их система не будет работать так, как они себе это представляли. Впоследствии система была признана непрактичной и была отменена после того, как значительное количество времени, усилий и других ресурсов было выделено и в конечном итоге потрачено на проект - и все потому, что мысль & Quot; теория бесполезна & Quot ;.
Итак, после этой неудачи менеджеры думают, что & Ну, может быть, эта система была недооценена; в конце концов, в нашей стране очень много городов, и наши компьютеры просто не так быстры, как нам нужно, чтобы наша недавно отмененная система была успешной ".
Команда управления винит медленные компьютеры как причину провала проекта. В конце концов, они не являются экспертами в теории КС, в этом нет необходимости, и те, кто должен был быть экспертами по этой теме и могли бы сообщить им, не сделали этого.
Но у них есть другой проект. На самом деле проще. Они приходят через неделю и просят сказать следующее:
Пример 2 . У нас всего несколько серверов, и у нас есть программисты, которые продолжают отправлять программы, которые по неизвестным причинам заканчиваются бесконечными циклами и отключают серверы. Нам нужны вы написать программу, которая будет обрабатывать отправляемый код и определить, будет ли отправленная программа вызывать бесконечный цикл во время ее выполнения или нет, и решить, следует ли разрешить запуск представленной программы на этой основе. Вы можете сделать это?
Ваш дорогой друг снова принимает вызов и немедленно приступает к работе. После нескольких недель работы результатов нет, твой друг испытывает стресс и не знает, что делать. Еще одна ошибка ... твой друг теперь чувствует & "Тупой"! " из-за того, что не удалось решить эту & простую проблему " ... в конце концов, сам запрос сделал его звуковым простым.
К сожалению, ваш друг, настаивая на том, что & теория бесполезна " не осознавал, что, якобы, простой запрос был на самом деле неразрешимой проблемой с разрешимостью (то есть самой проблемой остановки), и что для нее не было известного решения. Это была невыполнимая задача.
Поэтому даже начало работы по решению этой конкретной проблемы было ошибкой, которую можно было избежать и предотвратить. Если бы существовала теоретическая основа для понимания того, что запрашивалось, они могли бы просто предложить другое и достижимое решение ... например, реализовать процесс мониторинга, который может просто kill -SIGTERM <id> любой процесс пользователь (согласно списку пользователей), который монополизирует ЦП на некоторый произвольный / разумный интервал при определенных допущениях (например, мы знаем, что каждый запуск программы должен был завершиться в течение 10 минут, поэтому любой экземпляр, выполняющийся на 20+ минут должно быть kill ред.)
В заключение, практика без теории похожа на здание без фундамента . Рано или поздно правильное давление под прямым углом заставит его упасть на себя . Нет исключений.
Вы когда-нибудь использовали это в своем повседневном кодировании?
Да, но не напрямую . Скорее, мы полагаемся на это косвенно . Предостережение заключается в том, что различные теоретические концепции будут более или менее применимыми в зависимости от проблемной области, над которой вы работаете.
Конечно, мы:
<Ол>Это факт, что тот, кто просто использует самолет для путешествий, не должен понимать теорию, которая вообще позволяла строить самолеты и летать ... но когда кто-то ожидается, что соберет указанные машины и заставит их работать ... действительно ли можно ожидать хорошего результата от человека, который не понимает даже принципов полета?
Действительно ли это было совпадением, что на протяжении большей части истории никто не мог построить летательный аппарат (а некоторые даже умерли, испытывая свои), пока братья Райт не поняли некоторые теоретические представления о полете и не смогли применить их на практике
Это не случайно. Сегодня у нас много работающих технологий, потому что люди, которые их создавали, понимали и применяли теоретические принципы, которые позволили им работать в первую очередь.
Я полагаю, это зависит от того, в какое поле вы входите.
