Когда теоретическая информатика полезна?
в классе мы узнали о проблеме остановки, машинах Тьюринга,сокращениях и т. д. Многие одноклассники говорят, что все это абстрактные и бесполезные понятия, и нет никакого смысла их знать (т. е. вы можете забыть их, как только курс закончится, и ничего не потерять).
Почему теория полезна? Вы когда-нибудь использовали его в своем повседневном кодировании?
24 ответов
когда я окончил колледж, я предположил, что я был наравне со всеми: "у меня есть BS в CS, и так делают много других людей, и мы все можем делать по существу то же самое.- В конце концов я обнаружил, что мое предположение ложно. Я выделялся, и мое прошлое во многом было связано с этим-особенно моя степень.
Я знал, что есть одна" небольшая "разница, в том, что у меня был "B. S." В CS, потому что мой колледж был одним из первых (предположительно № 2 в 1987 году) в стране чтобы получить аккредитацию для своей программы степени CS, и я закончил во втором классе, чтобы иметь эту аккредитацию. В то время я не думал, что это имеет значение.
после колледжа (USAFA) я провел четыре года в ВВС, два из которых применяли мою степень CS. Там я заметил, что очень немногие из моих коллег имели степени или даже подготовку, связанные с компьютерами. ВВС отправили меня на пятимесячную сертификационную подготовку, где я снова обнаружил отсутствие степеней или подготовки. Но вот я начал замечать разницу, стало совершенно очевидно, что многие люди, с которыми я сталкивался, на самом деле не знали, что они делают, и это включало людей с образованием или степенями. Позвольте мне проиллюстрировать.
в моей аттестационной подготовке ВВС было в общей сложности тринадцать человек (включая меня). Как офицеры ВВС или что-то в этом роде, мы все имели степень бакалавра. Я был в середине по возрасту и рангу (я был о-2 среди шести О-1 и шести о-3 и выше). В конце этой тренировки ВВС прорезиненно проштамповали нас всех одинаково компетентен приобретать, строить, проектировать, обслуживать и эксплуатировать любой компьютер или систему связи для любой части Министерства обороны.
к концу нашего пятимесячного обучения, наш класс был назначен программный проект, и мы были разделены на четыре группы по отдельности провести он. Наши инструкторы разделили класс, чтобы справедливо распространить "талант программирования", и они назначили роли лидера команды, технического лидера и разработчика. Каждой группе была предоставлена неделя для внедрения (в Ada) полноэкранного текстового пользовательского интерфейса (это было в 1990 году) для летного тренажера поверх библиотеки летной механики, предоставленной инструктором. Меня назначили техническим руководителем моей команды из четырех человек.
мой руководитель команды (у которого не было компьютерного диплома) попросил нас троих разделите проект на задачи, а затем назначьте треть из них каждому из нас. К середине первого дня я выполнил третью часть заданий, а остаток дня провел, помогая двум другим товарищам по команде, разговаривая с руководителем команды (BSing;^) и играя на компьютере.
на следующее утро (день второй) мой руководитель команды в частном порядке сообщил мне, что наши другие два товарища по команде не добились никакого прогресса (на самом деле нельзя было написать заявление "Если", которое будет компилироваться), и он попросил меня взять о своей работе. Я закончил весь проект к середине дня, и моя команда провела остаток дня, летая на симуляторе.
другой парень с сопоставимой степенью CS также был назначен техническим лидером для своей команды, и они закончили к концу третьего дня. Они также начали летать на своем симуляторе. Две другие команды не закончили работу и даже не добились значительного прогресса к концу недели. Нам не разрешили помогать другим командам, поэтому он остался на что.
с тех пор я провел почти два десятилетия в качестве подрядчика и иногда в качестве сотрудника, всегда занимаясь разработкой программного обеспечения плюс связанные с этим мероприятия (DBA, архитектор и т. д.). Я продолжал находить больше того же самого, и в конце концов я сдался по моему юношескому предположению.
Итак, что же я обнаружил? Не все равны, и это нормально-я не лучший человек, потому что я могу эффективно программировать, но я более полезен, если это то, что вам нужно от меня. Я понял, что мое прошлое действительно имеет значение.: выросший в семье электриков и инженеров-электриков, строительные наборы электроники , чтение буквально каждой компьютерной книги в школе / публичных библиотеках, потому что у меня не было доступа к реальной компьютер, затем переезд в новый город, где в моей школе были компьютеры., затем получить свой собственный компьютер в подарок, ходить в школы, где были компьютеры разных размеров и видов (от ПК до мейнфреймов), получение диплома в очень хорошей инженерной школе, необходимость писать множество программ на разных языках на разных компьютерах, необходимость писать жесткие программы (например, моя собственная виртуальная машина с пользовательским языком сборки или Huffman реализация сжатия, и т. д.), необходимость устранения неполадок для себя, создание собственных компьютеров из частей и установка всего программного обеспечения, так далее.
в конечном счете, я узнал, что мои способности построены на основе знания того, как компьютеры работают от электрического уровня на-дискретные электронные компоненты,схемы, подсистемы, интерфейсы, протоколы, биты, байты, процессоры, устройства, драйверы, библиотеки, программы, системы, сети, на до массивных конгломераты корпоративного класса, над которыми я сейчас работаю. Так что, когда эта чертова штука плохо себя ведет, я точно знаю, как и почему. И я знаю, что нельзя сделать так же хорошо, как и то, что можно. И я много знаю о том, что было сделано, что было опробовано и что осталось относительно неисследованным.
самое главное, после того, как я узнал все это, я узнал, что я ни черта не знаю. Перед лицом всего, что потенциально может быть известно, мое знание мизерный.
и я вполне доволен. Но я рекомендую вам попробовать.
история:
когда я получил свою первую работу по программированию из аспирантуры, ребята, которые владели компанией, в которой я работал, были пилотами. Через несколько недель после того, как меня наняли, один из них задал мне такой вопрос:--1-->
в Арканзасе есть 106 аэропортов. Не могли бы вы написать программу, которая найдите кратчайший маршрут, необходимый для приземлиться на каждом из них?
Я серьезно думал, что он спрашивает меня о моих знаниях о путешествиях Проблема продавца и NP-полнота. Но оказалось, что нет. Он ничего об этом не знал. Он действительно хотел программу, которая будет находить кратчайший путь. Он был удивлен, когда я объяснил, что существуют 106-факториальные решения, и найти лучшее из них-хорошо известная вычислительно трудноразрешимая задача.
Так что это один пример.
конечно, это полезно.
представьте себе разработчика, работающего над шаблоном. Вы знаете вид вещи...
Blah blah blah ${MyTemplateString} blah blah blah.
Он начинается просто, с нахального маленького регулярного выражения, чтобы сформировать замены.
но постепенно шаблоны становятся немного более причудливыми, и разработчик включает в себя функции для шаблонов списков и карт строк. Для этого он пишет простую грамматику и генерирует синтаксический анализатор.
получаете очень хитрый механизм шаблонов может в конечном итоге включать синтаксис условной логики для отображения различных блоков текста в зависимости от значений аргументов.
кто-то с теоретическим опытом в CS признал бы, что язык шаблонов медленно становится полным Тьюринга, и, возможно, шаблон интерпретатора был бы хорошим способом его реализации.
построив интерпретатор для шаблонов, компьютерный ученый может заметить, что большинство шаблонные запросы являются дубликатами, восстанавливающими одни и те же результаты снова и снова. Таким образом, кэш разработан, и все запросы маршрутизируются через кэш перед выполнением дорогостоящего преобразования.
кроме того, некоторые шаблоны намного сложнее других и требуют гораздо больше времени для рендеринга. Возможно, кому-то приходит в голову оценить выполнение каждого шаблона перед его рендерингом.
но подождите!!! Кто-то из команды указывает, что, если язык шаблона действительно, Тьюринг завершен, тогда задача оценки времени выполнения каждой операции рендеринга является экземпляром проблемы остановки!! Фу, не делай этого!!!
то, что я использую больше всего:
- вычислительная сложность для написания алгоритмов, которые масштабируются изящно
- понимание того, как распределение памяти, подкачка и кэширование процессора работают, поэтому я могу написать эффективный код
- понимание структур данных
- понимание резьбы, блокировки и связанных с ними проблем
Что касается этого материала на машинах Тьюринга и т. д. Я думаю, что это важно, потому что он определяет ограничения под которым мы все управляем. Это важно ценить.
это разница между изучением алгебры и обучением использованию калькулятора
Если вы знаете алгебру, вы понимаете, что одна и та же проблема может проявляться в разных формах, и вы понимаете правила преобразования проблемы в более краткую форму
Если вы только знаете, как использовать калькулятор, вы можете потратить много времени на нажатие кнопок на проблему, которая либо (a) уже решена, (b) не может быть решена, или (c) похожа на какую-то другую проблему (решенный или не решенный), который вы не узнаете, потому что он в другой форме
представьте на мгновение, что информатика-это физика... может, вопрос покажется глупым?
мой друг делает работу над языком с некоторыми шаблонами. Меня пригласили на консультацию. Часть нашего обсуждения была посвящена функции шаблона, потому что если шаблоны были завершены Тьюрингом, они должны были бы действительно рассмотреть свойства VM-ish и как/если бы их компилятор поддерживал его.
моя история до этого момента: теория автоматов все еще преподается, потому что она все еще имеет значение. Проблема остановки все еще существует и ограничивает то, что вы можете делать.
теперь, эти вещи имеют отношение к жокею базы данных, выбивающему код c#? Скорее всего, нет. Но когда вы начнете переходить на более продвинутый уровень, вы захотите понять свои корни и основы.
хотя я не применяю их непосредственно в повседневной работе, я знаю, что мое образование в области формальных компьютерных наук повлияло на мой мыслительный процесс. Я, конечно, избегаю некоторых ошибок с самого начала, потому что у меня есть уроки, извлеченные из формальных подходов, привитых мне.
Это может показаться бесполезным, пока они его изучают; но я уверен, что ваш одноклассник в конечном итоге столкнется с проблемой, когда они будут использовать то, чему их учили, или, по крайней мере, мыслительные модели позади он...
воск... Воск... Воск... Воск... Какое это имеет отношение к карате?
на одном задании мне была поставлена задача улучшить алгоритм трассировки сети нашей электрической модели распределения, поскольку тот, который они использовали, был слишком медленным. Трехфазная сеть состояла по существу из трех n-деревьев (так как петли не допускаются в электрических сетях). Сетевые узлы были в базе данных, и некоторые из исходной команды не могли понять, как построить модель в памяти, поэтому трассировка была выполнена путем последовательного выбора глубины в базе данных, фильтрации на каждом этапе. Итак, чтобы проследить узел десять узлов от подстанции потребовали бы по крайней мере 10 запросов к базе данных (первоначальные члены команды были свистками базы данных, но не имели приличного фона в алгоритмах).
Я написал решение, которое преобразовало 3 N-дерева сетей узлов из базы данных в структуру данных, где каждый узел был сохранен один раз в массиве структуры узла, и отношение n-дерева было преобразовано в три двоичных дерева, используя дважды связанные указатели внутри массива, чтобы сеть могла быть легко прослеживается в обоих направлениях.
Это было по крайней мере на два порядка быстрее, Три на действительно длинных следах вниз по течению.
Это классическая дихотомия, между "как" и "что". Ваши одноклассники смотрят на" как " программировать программное обеспечение, и они очень сосредоточены на ближайшем фокусе; с этой точки зрения, с точки зрения реализации, кажется, что знание таких вещей, как остановка состояний и машины Тьюринга, не имеет значения.
"как"очень мало фактической работы, которую вы ожидаете сделать с информатикой. На самом деле, большинство успешных инженеров, которых я знаю, вероятно, поставили бы его меньше чем 20 процентов от реальной работы. "Что" делать гораздо важнее; и для этого основы информатики имеют решающее значение. "То, что" вы хотите сделать, относится гораздо больше к дизайну, чем к реализации; и хороший дизайн... ну, давайте просто назовем это "нетривиальный".
- К. А. Р. Хоар
удачи в учебе!
Я думаю, что понимание фундаментальных моделей вычислений полезно: конечно, вам никогда не нужно быть в состоянии перевести машину Тьюринга в машину регистра на практике, но научиться видеть, что две очень разные проблемы на самом деле являются примерами одной и той же концепции, является критическим навыком.
большинство знаний не является "практическим", но помогает вам соединить точки способами, которые вы не можете предвидеть, или дает вам более богатый словарь для описания более сложных идей.
значение имеют не конкретные проблемы, которые вы изучаете, а принципы, которые вы изучаете, изучая их. Я использую концепции об алгоритмах, структурах данных, языках программирования и операционных системах каждый день на своей работе. Если вы работаете программистом, вы все время будете принимать решения, влияющие на производительность системы. Вам нужно иметь прочную основу в фундаментальных абстрактных понятиях, чтобы сделать правильный выбор.
Если вы работаете в компании, которая делает новаторскую работу, важно уметь взаимодействовать с архитекторами и разработчиками, Какие преимущества. Существует много шумихи о всех видах технологий и позиционирования себя может быть трудно. Когда вы формулируете свои инновации в научных и теоретических терминах, вы определенно получаете преимущество, и клиенты чувствуют, что вы-настоящая вещь. Я могу сказать людям: есть новый способ борьбы с состоянием, кодированием и недетерминизмом (т. е. сложности), и вы определенно можете быть более продуктивными, чем сегодня.
Если вы берете длинный взгляд в своей карьере, изучение теории даст вам глубину, глубину, которую вам нужно расти. Отдача от инвестиций в изучение вашего 5-го или 6-го языка программирования будет намного меньше, чем изучение вашего 2-го и 3-го. Ознакомление с теорией даст вам представление о реальной инженерии, о том, где находятся степени свободы и как вы можете сделать правильные компромиссы.
в важные понятия 1) состояние, 2) кодирование, 3) Недетерминизм. Если вы не знаете, они вам не помогут. Теория должна дать вам общую картину и понимание того, как Основные понятия подходят друг к другу. Это поможет вам отточить интуицию.
пример: некоторые из ответов выше упоминают проблему остановки и машины Тьюринга. Когда я наткнулся на статью Тьюринга в колледже, я совсем не чувствовал себя просветленным. Однажды я наткнулся на теорему Геделя о неполноте и Геделя. в частности, нумерация. Все стало обретать смысл. Много лет спустя я прочитал о Георге Канторе в книжном магазине. Теперь я действительно начал понимать машины Тьюринга, проблема остановки. Попробуйте сами и посмотрите "Диагональный аргумент Кантора" в Википедии. Это одна из самых удивительных интеллектуальных вещей, с которыми вы когда-либо сталкивались.
пища для размышлений: типичная машина Тьюринга-не единственный способ спроектировать машину перехода состояния. Машина Тьюринга с двумя чем одна лента даст вам намного больше скорости для ряда алгоритмов. http://www.math.ucla.edu / ~ynm / papers / eng.ps
вы можете подвергнуть себя этим прозрениям более эффективно, чем я, прочитав эту книгу. Ссылка внизу этого поста. (По крайней мере, ознакомьтесь с оглавлением на Amazon, чтобы получить представление о том, что это такое):
Я нашел книгу Розенберга сенсационным. http://www.amazon.com/The-Pillars-Computation-Theory-Nondeterminism/dp/0387096388 Если у вас есть только одна книга по теории ИМХО, это должно быть одно.
после того, как я закончил CS, я подумал аналогично: вся куча теорий, которые мы изучали, совершенно бесполезны на практике. Это оказалось правильным в течение короткого периода времени, однако в тот момент, когда вы имеете дело со сложными задачами, теория определенно более ценна, чем практика. каждый после нескольких лет кодирования может писать некоторые программы, которые "работают", но не каждый способен понять, как. независимо от того, что большинство из нас будет иметь дело в определенный момент с проблемами производительности, сеть задержки, precission, масштабируемость etc. На данном этапе теория имеет решающее значение. чтобы разработать хорошее решение при работе со сложными системами, очень важно знать, как работает управление памятью, понятия процесса и потоков, как им назначается память или эффективные структуры данных для производительности и так далее.
однажды, например, я работал над проектом, включающим множество математических вычислений, и в определенный момент наше программное обеспечение потерпело неудачу. в то время как отладка я выяснил, что после некоторой математической операции я получил число как двойное значения 1.000000000002, но с математической точки зрения не могло быть > 1, которое на каком-то более позднем этапе в программе давало легендарное Нэн исключения. я потратил некоторое время, чтобы понять это, но если бы я уделил больше внимания "приближение Double и Float
Я не использую его на ежедневной основе. Но это дало мне много понимания, которое помогает мне каждый день.
Я обнаружил, что все, что мне нужно для ежедневного блаженства от теоретического мира CS, - это произнесение мантры "низкое сцепление и высокое сцепление". Роджер С. Прессман сделал это раньше Стив Макконнелл сделал его модным.
Ya, я обычно использую диаграммы состояний для разработки формы и потока программы. Как только это работает в теории, я начинаю кодирование и тестирование, проверяя состояния по ходу.
Я считаю, что они также являются полезным инструментом для объяснения поведения процесс других людей.
простой. Например: если я использую RSACryptoServiceProvider Я хотел бы знать, что это такое и почему я могу доверять ему.
потому что шаблоны C++ на самом деле являются своего рода лямбда-исчислением. См www.cs.nott.ac.uk/types06/slides/michelbrink_types_06.pdf
сейчас я изучаю свой курс распределенных алгоритмов. Существует глава о отказоустойчивости, и она содержит некоторые доказательства на верхней границе для того, сколько процессов может потерпеть неудачу (или плохо себя вести), чтобы распределенный алгоритм мог правильно ее обрабатывать.
для многих проблем граница для процессов неправильного поведения составляет до одной трети от общего числа процессов. Это очень полезно, на мой взгляд, потому что вы знаете, что бессмысленно пытаться разработать лучший алгоритм (под данное предположение.)
даже если теоретические курсы не будут использоваться напрямую, это может помочь вам лучше подумать о чем-то.
честно говоря, я не согласен со многими ответами здесь. Я написал свой первый компилятор (для удовольствия; я действительно слишком много кофе / свободного времени), не пройдя курс в компиляторах; в основном я просто сканировал код для другого компилятора и следовал шаблону. Я мог бы написать парсер на букву " С " на макушке, но не думаю, что смог бы вспомнить, как нарисовать автомат, если бы от этого зависела моя жизнь.
когда я решил, что хочу поставить типа на моем игрушечном (императивном) языке программирования я сначала просмотрел, вероятно, пять статей, уставившись на что-то под названием "типизированное лямбда-исчисление".... этот.... ****....? Сначала я попытался реализовать что-то с "общими переменными" и "негенерическими переменными" и понятия не имел, что происходит. Затем я отбросил все это и сидел там с блокнотом, выясняя, как я мог бы реализовать его практически с поддержкой всех необходимых мне вещей (подтипирование, первоклассные функции, параметризованные типы, и т. д.) С помощью нескольких дней мышления и написания тестовых программ я потратил больше недели, чтобы попытаться выяснить теоретическое дерьмо.
знание основ вычислений (т. е. как работает виртуальная память, как работают файловые системы, потоковое/планирование, SMP, структуры данных) оказались очень полезными. Теория сложности и материал Big-O иногда оказывались полезными (особенно полезными для таких вещей, как дизайн РСУБД). Проблема остановки и автоматы/Turing Машинная теория? Никогда.
без основной теории существует нет практика.
почему теория полезна?
теория является основой, на которой строятся другие вещи. Когда теория applied, практика результат.
сегодня компьютеры. общий компьютер сегодня смоделирован и построен поверх машины Тьюринга, которая, чтобы сохранить ее простой, является абстрактной/теоретической моделью для вычислений. Эта теоретическая модель лежит на фонд вычислений, и все вычислительные устройства, которые мы используем сегодня, от серверов высокого класса до карманных телефонов, работают, потому что основа-это звук.
рассмотрим алгоритм анализа. In простые термины, анализ алгоритмов и теория временной сложности использовались для классификации задач (например, P, NP, EXP и т. д.), а также как алгоритмы, которые мы имеем, ведут себя при попытке решить различные проблемы в разных классах.
предположим, один из ваших друзей получает работу в каком-то месте X и, пока там, менеджер делает несколько простых запросов, таких как следующие примеры:
Ex 1: мы имеем большой парк кораблей доставки которые посещают различное города в нескольких штатах. Нам нужно вы чтобы реализовать систему, чтобы выяснить, какой самый короткий маршрут для каждого транспортного средства и выбрать оптимальный одна из всех возможностей. Ты можешь это сделать?
думая, что теория "бесполезна" , ваши друзья не понимают, что им только что дали проблему коммивояжера (TSP) и начали разрабатывать эту систему без второй мысли, только чтобы обнаружить их наивную попытку проверить все возможности, как первоначально просили, настолько медленны, что их система непригодна для любых практических целей.
В самом деле, у них есть Не знаю, почему система работает на "приемлемом" уровне при проверке 5 городов, но становится очень медленной в 10 городах и просто замерзает, когда доходит до 40 городов. Они считают, что это только "2x и 8x больше городов, чем 5 city test" и интересно, почему программа не просто требует " 2x и 8x больше время" соответственно...
понимание теории позволило бы им понять следующее, По крайней мере, с первого взгляда:
- это TSP
- TSP является NP-hard
- порядок роста их алгоритма O (n!)
цифры говорят сами за себя:
+--------------+-------+-----------------------------------------------------------------+
| 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
+--------------+-------+-----------------------------------------------------------------+
они могли с самого начала понять, что их система была не собирается работать, как они себе это представляли. Позже система была признана непрактичной и отменена после того, как значительное количество времени, усилий и других ресурсов было выделено на проект и в конечном итоге потрачено впустую-и все потому, что мысль "теория бесполезна".
Итак, после этого сбоя менеджеры думают: "Ну, может быть, эта система была недооценена; в конце концов, в нашей стране много городов, и наши компьютеры просто не так быстры, как нам нужно, чтобы наша недавно отмененная система была успех."
команда управления обвиняет медленные компьютеры в качестве причины сбоя проекта. В конце концов, они не эксперты в теории CS, не должны быть, и те, кто должен быть экспертами по этой теме и мог бы их проинформировать, не сделали.
но у них на уме другой проект. Проще на самом деле. Они приходят через неделю и просят сказать следующее:
Ex 2: у нас всего несколько серверов и у нас есть программисты кто продолжает отправлять программы, которые по неизвестным причинам заканчиваются бесконечными циклами и захватывают серверы. Нам нужно вы написать программу, которая будет обрабатывать отправляемый код и определять, приведет ли представленная программа к бесконечному циклу во время ее запуска или нет, и решить, следует ли разрешить запуск представленной программы на этой основе. Ты можешь это сделать?
ваш дорогой друг снова принимает вызов и немедленно приступает к работе. После нескольких недель работы нет никаких результатов, ваш друг напряжен и не знает, что делать. Еще одна неудача... ваш друг теперь чувствует себя "глупым", потому что не смог решить эту"простую проблему"... ведь сама просьба сделала это звук простой.
к сожалению, Ваш друг, настаивая на том, что "теория бесполезна", не понял, что якобы простой запрос на самом деле является неразрешимой проблемой о разрешимости (т. е. остановке сама проблема), и что для нее не было известного решения. Это была невыполнимая задача.
поэтому даже начало работы по решению этой конкретной проблемы было предотвратимой и предотвратимой ошибкой. Если бы теоретические рамки, чтобы понять, что запрашивалось, были на месте, они могли бы просто предложить другое, и достижимо, решение... например, реализация процесса мониторинга, который может просто kill -SIGTERM <id> любой пользователей процесс (согласно списку монополизирует CPU для некоторого произвольного / разумного интервала при определенных предположениях (например, мы знаем, что каждый запуск программы должен завершиться в течение 10 минут, поэтому любой экземпляр, работающий в течение 20+ минут, должен быть killed).
В заключение практика без теории подобна зданию без фундамента. Рано или поздно, правильное количество давления под прямым углом заставит его рухнуть на себя. Нет исключения.
вы когда-нибудь использовали его в своем повседневном кодировании?
Да, но не напрямую. Скорее, мы полагаемся на него косвенно. Нюанс здесь заключается в том, что различные теоретические концепции будет более или менее применимы в зависимости от проблемной области вы будете работать.
мы:
- ежедневно используйте компьютеры, которые основаны на вычислительных моделях (например, turing машины)
- написать код, который опирается на теорию вычислимости (например, что даже вычислимо) и лямбда-исчисление (например, для языков программирования)
- опираться на теорию цвета и модели (например, цветовые модели RGB и CMYK) для цветных дисплеев и печатание, etc.
- теоремы Эйлера в компьютерной графике, так что матрицы могут быть построены для вращения объектов вокруг произвольных осей и так далее...
Это факт, что кто-то, кто просто использовать самолет для путешествия не нужно понимать теорию, которая даже позволила самолетам быть построены и летать в первую очередь... но когда кто-то ожидается построить сказал машины и заставить их работать... можно ли ожидать хорошего результата от человека, который не понимает даже принципов полета?
было ли это действительно совпадением, что на протяжении большей части истории никто не смог построить летающую машину (а некоторые даже умерли, тестируя их), пока Братья Райт поняли некоторые теоретические концепции полета и сумели воплотить их в жизнь?
- Это не случайно. Сегодня у нас много рабочих технологий, потому что люди, которые их построили, понимали и применяли теоретические принципы, которые позволили им работать в первую очередь.