Наверное, каждый из хабровчан хотя бы раз в жизни слышал это выражение. Действительно, что может быть проще? Однако я знавал преподавателя математического анализа, который, услыхав подобное, ехидно улыбался в усы и предлагал доказать этот факт. После этого у говорившего обычно случался когнитивный диссонанс.

И действительно, как же доказать, что 2 × 2 = 4? Ответ под хабракатом.

Дисклеймер

Данная статья не содержит ничего нового для читателей с серьёзным математическим образованием. Также, вполне вероятно, она будет неинтересна людям с чисто инженерным складом ума. Этот текст писался в расчёте на тех, кому интересны основания математики, но кто до сих пор не нашёл времени и сил в них разобраться.

Введение

В данной статье сделан обзор деревьев принятия решений (Decision trees) и трех основных алгоритмов, использующих эти деревья для построение классификационных и регрессионных моделей. В свою очередь будет показано, как деревья принятия решения, изначально ориентированные на классификацию, используются для регрессии.

Деревья принятия решений

Дерево принятия решений — это дерево, в листьях которого стоят значения целевой функции, а в остальных узлах — условия перехода (к примеру “ПОЛ есть МУЖСКОЙ”), определяющие по какому из ребер идти. Если для данного наблюдения условие истина то осуществляется переход по левому ребру, если же ложь — по правому.

В статье я расскажу небольшую историю про маленькую техническую задачку и о том, как её решали разные люди вокруг. Быть может этот рассказ поможет читателю вынести несколько уроков о том, какие временами встречаются ошибки.
Немножко матана инклудэд.

Идея распознавать людей по радужной оболочке появилась в далёком 1987 у доктора Джона Доугмана и была запатентована в 1989. Примерно тогда же появился прототип. На тот момент это была вершина технологии. Пару лет до первой коммерческой цифровой камеры + алгоритм обработки изображения на компьютерах уровня i386/i486. До сих пор я не представляю, как можно получать на таком оборудовании стабильный результат.
Задачка о которой я хочу рассказать появилась на свет где-то в 2006-2009 годах. Процессоры к этому времени несколько ускорились, появились хорошие камеры, патент 1989 года истёк и системы распознавания по глазам теперь получил право делать каждый. Люди, которые решили сделать клон системы захотели использовать современные технологии и улучшить алгоритм. Самое первое, что бросалось в глаза — старый алгоритм сравнения глаз использовал изображение глаза в близком ИК диапазоне. То, что глаза бывают цветными не учитывалось.

Введение

Наука, связанная с обработкой данных, продолжает волновать людей, однако реальные результаты нередко вызывают разочарование у заинтересованных бизнесменов. Как мы можем снизить риски и обеспечить соответствие результатов ожиданиям? Работа в качестве технического специалиста на стыке НИОКР и коммерческих операций дала мне представление о проблемах, которые стоят на этом пути. Я представляю свою личную точку зрения на наиболее распространённые виды провалов и неудач проектов, связанных с информатикой.

Бизнес-анализ эволюционировал от статичных отчётов, рассказывающих, что произошло, до интерактивных информационных панелей, с помощью которых вы можете углубиться в данные и попытаться понять, почему это произошло. Новые источники больших данных, включая устройства интернета вещей, подталкивают бизнес перейти от пассивной аналитики — когда мы смотрим на какой-то период в прошлом и ищем тенденции, или раз в день проверяем на наличие проблем — к активной аналитике, способной предупредить о чём-то заранее и позволяющей создавать информационные панели с обновлением в реальном времени. Это помогает лучше использовать операционные данные, которые куда полезнее, если они получены «только что», пока ещё не изменились условия.

Странно, но факт

• Абсолютно все стандарты управления проектами и компаниями говорят о необходимости управления рисками. Предлагаются различные модели, инструменты и термины. Каждый ПМ понимает, что это важно. И проходят тренинги. И даже пытаются выполнять такую практику (или процесс) как Risk Management. Но не все (большинство) видят в этом смысл и пользу на практике. В лучшем случае заводят регистры рисков (про которые скоро забывают), в худшем говорят, что управление рисками происходит в ходе ежедневной коммуникации (непонятно, правда, что имеется ввиду под рисками и управлением.
• При наличии на проектах Risk register-а менеджмент компании считает что есть недостаток в про-активном управлении проекта и в коммуникациях с заказчиком, который регулярно жалуется на неожиданные проблемы на проекте.
• Проджект менеджеры и Проектные команды жалуются на большие затраты времени на работу с рисками (и, очевидно, отсутствием эффекта, а то бы не жаловались.

Эти и многие подобные наблюдения были сделаны мной в ходе внедрения системы управления качеством и проведения аудитов процессов в IT компании. В частности, процессов управления проектом. Как и любое нововведение, внедрение правил работы должно сопровождаться обоснованием зачем это нужно. Для этого, в дополненение к навыкам убеждения, необходимы знание теории и практических примеров — как негативных, так и позитивных. На них и основаны мои выводы о секретах эффективного Управления Рисками.

Если вы читаете этот материал – на это, вероятно, есть две причины:

— Вы ищете оптимальное решение управления проектом, который нужно завершить к определенному сроку.
— Вы ищете определение аббревиатуры PERT.

В любом случае, вы находитесь в правильном месте. Мы хотим поделиться основными преимуществами техники оценки и анализа проектов и выяснить, что же из себя представляет PERT.

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

Для создания модели предметной области сначала строится модель наших представлений. Описание наших представлений содержится в метамодели (например, в нотации BPMN). Метамодели, в свою очередь, строятся на основе мета-метамодели. Однако, наши представления имеют очень непростую структуру, которая до сих пор не имеет формального описания. Поэтому построение метамодели и мета-метамодели сильно затруднено. Попытку описать эту структуру предприняли греки, когда придумали основы логики. Способы нашего мышления изучали математики, когда столкнулись с парадоксами, пытаясь построить основы своей науки. Казалось бы, прогресс есть, но по какой-то причине, остановившись на формальном описании инструментов логического вывода, математики не сделали попытку применить полученные наработки к моделированию нашего мира (наверно, потому что для них – это прикладная задача, не вызывающая интереса).



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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Написано в сотрудничестве с Ревазом Бухрадзе и Кириллом Перминовым

1. Введение

Offline oбмен сообщениями сейчас является одним из наиболее популярных способов общения (1, 2, 3) — судя по аудитории способов общения и динамике её роста.

При этом, ключевым требованием при обмене сообщениями всегда будет являться полное соответствие отправленного сообщения – полученному, то есть передача данных не должна необратимо искажать сами данные. Естественное желание – сэкономить привело к созданию алгоритмов сжатия данных, которые, убирают естественную избыточность данных минимизируя объём хранимых и передаваемых файлов.

Максимально достигаемый объём сжатия, гарантирующий однозначное восстановление данных, определяется работами К. Шеннона по теории информации, и в общем-то является непреодолимым так как изъятие не только избыточной, но и смысловой информации не позволит однозначно восстановить исходное сообщение. Стоит отметить, что отказ от точного восстановления в некоторых случаях и не является критически важным и используется для эффективного сжатия графических, видео и музыкальных данных, где потеря несущественных элементов оправдана, однако о общем случае целостность данных, куда важнее их размера.

Соответственно интересным является вопрос о том, можно-ли не нарушая положения теории информации передать сообщение объёмом меньше, чем минимальный объём, который может быть достигнут при самом лучшем сжатии данных.

Чтобы изучить новую технологию достаточно месяца. На этом можно было бы закончить эту статью, толком не начав ее. Однако я продолжу и расскажу вам, как пришла к такому выводу, что можно сделать, чтобы ускорить процесс обучения, а также перечислю основные проблемы изучения новых технологий и, самое главное, способы их решения.

Для начала отмечу, что названный срок в месяц — это большое допущение и приблизительная оценка. Все зависит от вашего начального уровня и сложности той технологии, которой вы решили овладеть. Кому-то достаточно посмотреть исходники в библиотеке, а кому-то необходимо кропотливо разбираться во всех нюансах. И все равно я уверена, что много времени вам не потребуется.

Слушайте и смотрите новую подборку лекций Техносферы Mail.Ru. На этот раз представляем в открытом доступе весенний курс «Введение в анализ данных», на котором слушателей знакомят со сферой анализа данных, основными инструментами, задачами и методами, с которыми сталкивается любой исследователь данных в работе. Курс преподают Евгений Завьялов (аналитик проекта Поиск Mail.Ru, занимающийся извлечением полезных бизнесу знаний из данных, генерируемых поисковым движком и десктопными приложениями), Михаил Гришин (программист-исследователь из отдела анализа данных) и Сергей Рыбалкин (старший программист из студии Allods Team).

Лекция 1. Введение в Python

Из первой лекции вы узнаете, что такое анализ данных, какие инструменты используют для анализа данных, а также как работает Python.

Английский учёный из Плимутского университета Майк Макалох [Mike McCulloch] в своей работе попытался дать объяснение принципу действия «невозможного» двигателя EmDrive, который вот уже несколько лет ставит в тупик специалистов. Для этого учёному пришлось дать объяснение такому фундаментальному понятию физики, как инерция.

Двигатель EmDrive придумал в начале 2000-х британский инженер Роджер Шойер. Он представил общественности свою идею о двигателе, по сути состоящем из металлического усечённого конуса и магнетрона. По его расчётам, отражающиеся внутри конструкции электромагнитные волны должны создавать тягу без всяких реактивных компонентов.

Естественно, он был поднят на смех, поскольку закон сохранения импульса не позволяет создавать подобные устройства. Но, начиная с 2008 года и опыта китайских учёных, а затем – нескольких инженеров-энтузиастов, и заканчивая опытами уважаемых инженеров из НАСА, накапливается всё больше подтверждений тому, что этот странный двигатель всё-таки работает.

Может ли быть так, что «зима искусственного интеллекта», наступившая в конце 70-х годов прошлого века, на самом деле до сих пор не закончилась, а все коммерческие решения, связанные с использованием ИИ, стали жертвой маркетинга, установившего правило: вам гораздо легче продать продукт, если заявите, что он работает на основе искусственного интеллекта? Нечто подобное уже случалось раньше. Классические экспертные системы, ориентированные на текстовый человеко-машинный интерфейс, пережили расцвет в 70–80-х годах прошлого века, а затем скатились в глубокий кризис, из которого так и не вышли. Интересно провести параллели с современными когнитивными системами, имеющими признаки искусственного интеллекта.

Главный успех эры когнитивных вычислений сейчас связывают с деятельностью IBM Watson. Но действительно ли это успех, или попытка выдать желаемое за действительное?

Bridgewater Associates – самый крупный хедж-фонд в мире, который обслуживает множество институциональных клиентов: пенсионные и благотворительные фонды, некоммерческие организации, правительства и центральные банки. Сейчас хедж-фонд управляет активами более чем на 150 миллиардов долларов. Чтобы добиться таких впечатляющих результатов, основатель компании Рей Далио (Ray Dalio) приложил немало усилий, в том числе для создания уникальной корпоративной культуры.

Основатель Bridgewater в первую очередь знаменит своим неординарным подходом к управлению, и идея переложить решение управленческих задач на искусственный интеллект вполне согласуется с его принципами.

Эта статья открывает серию статей — если окажется, что Хабраколлеги сочтут ее интересной, ибо первое правило публичных выступлений гласит: рассказывай людям о том, что им интересно!

Если вы раньше не выступали на публике или боитесь это делать — вам под кат. Если вы считаете себя опытным докладчиком, для вас будет вторая статья серии.

В сегодняшней статье я пишу о том, как выступать, и очень мало пишу о содержании доклада. Если из комментариев станет понятно, что надо еще рассказать о композиции доклада (постановка задачи -> варианты решений -> процесс выбора -> выбранное решение -> результат) или об основах публичной речи (не «экать», не «мыкать», не говорить через слово «т-скыть» и не заканчивать фразы ненормативными междометиями) — расскажу в следующий раз.

Историческая справка: на Хабре по этой теме уже было небольшое обсуждение год назад.

Эпоха путешествий во времени еще не наступила, а человечество уже давно пытается разрешить сопутствующие им парадоксы. Мы поговорим о самом очевидном из них: что же все-таки произойдет при вмешательстве в ход истории? Существует несколько вариантов того, как поток времени реагирует на действия путешественника из будущего. Эти модели можно увидеть в фантастических фильмах, о них все больше начинают говорить ученые, но какая модель ближе к истине — единого мнения пока нет. Мы только начинаем проникать в тайны времени, и еще не обладаем возможностью экспериментировать с перемещениями в прошлое. Что же можно прояснить в данном вопросе уже сейчас? Под катом нас ждет экскурсия по основам механики времени, мы порассуждаем о парадоксах, и проведем небольшой эксперимент. Да, это будет испытание виртуальной машины времени, построенной на основе алгоритма «Жизнь»!

Известно, что на старых картах, на неизведанных территориях, часто помещали зловещее предупреждение: «Здесь живут драконы». Вероятно, смысл этого предупреждения состоял в том, что не стоит входить в это пространство мира, не будучи готовыми сражаться с внушающим ужас противником. Всё что угодно может случиться на этих загадочных просторах, и нередко такое «что угодно» может закончиться очень плохо.

Программисты, возможно, являются несколько более цивилизованными, чем средневековые рыцари — однако это вовсе не означает, что современный технический мир не имеет своих технических драконов, поджидающих нас в непредвиденных местах: сложные проблемы, которые всплывают именно тогда, когда подходит срок сдачи работы или в моменты особенно высоких нагрузок и ответственной работы; конкуренты, которые прочитали руководство и знают, что недостаточно хорошо реализовано; злые «бесы», которые знают, как использовать неустранённые до конца баги и дефекты программ, причём узнают это часто сразу же после того, как программа сдана в использование.

Находятся люди, которые спокойно спят ночью, согреваемые своей наивной уверенностью, что компьютеры совершенно предсказуемы и без устали выдают потоком правильные ответы. Как же мало им ведомо! Несмотря на серьёзнейшие усилия разработчиков чипов, создателей языков и миллионов программистов, есть ещё в программировании опасные чащи, которые могут погубить даже самых продвинутых из программистов и разработчиков.

Вот семь из устрашающих уголков мира программирования, на которых легко можно написать: «Здесь живут драконы».

В программировании занято гораздо больше мужчин, чем женщин. С этим фактом не поспоришь, поэтому любому руководителю необходимо учитывать психологию мужчин в программировании.

Обратимся к древним временам, когда мужчина охотился на мамонтов, а женщины сидели дома, рожали детей и готовили еду. Чтобы охотиться, мужчина очень долго готовился, точил топор, готовил стрелы и лук. Потом он долго сидел в засаде и наконец делал выстрел или наносил удар. Эта особенность поведения трансформировалась и дожила до наших дней. Мужчину отличает способность к повышенной концентрации на выполняемой работе. Это большой плюс и большой минус. В отличие от женщины мужчина не может выполнять несколько дел одновременно.