Category: наука

cartoon

О точных науках

Когда я стал постарше, я, будучи воспитанным как ученый-математик, изменил свое отношение к гуманитарным наукам.

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

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

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

Собственно, высшая математика от низшей и отличается владением этим профессиональным жаргоном (арго). Когда ты понимаешь, что означают эти "функция быстро растет", и умеешь этим языком говорить.

В этот момент ты становишься гуманитарием. Освобождаешься от оков "строгости". И начинаешь, наконец, познавать мир.

Математика - это неплохая тренировка ума. Но мир так интересен и разноообразен :). Его описывает не она. Искусство. Только оно способно кратко и точно донести всю правду о мире.
cartoon

Как пользоваться электронной почтой

Вопрос, казалось бы, не стоит выеденного яйца. Каждый думает, что он умеет отправлять письма, не так ли? Так в чем же тогда дело?

А тогда почему многие на работе регулярно пишут письма так, что им хоть почтовый аккаунт вырубай? Если кто не в курсе - электронная почта есть самый, сцуко, опасный способ коммуникации на работе. Это - пост-памятка, который я пишу для себя. Заебался объяснять в двадцатый раз - буду давать ссылку.

Collapse )
cartoon

Прикладная теория вероятности

Поганкин с силой грохнул деревянным стаканом об стол, и стал медленно приподнимать его край, подглядывая в открывающуюся щель. Затаив дыхание, вокруг стакана сгрудилось еще три человека.

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

Collapse )

Disclaimer:
1. Все персонажи данной истории, как обычно, выдуманы, как их имена и поведение, и никакого отношения реальным людям и событиям не имеют. Любые совпадения и аллюзии являются совершенно случайными, и остаются на совести читателя.
2. Для читетелей тонкой душевной организации. Обилие ненормативной лексики является нормальным для данной серии историй. Никаких преувеличений история не содержит - персонажи ведут себя естественно. Это жизнь.
3. "Яйца" (Yatzy), он же "покер на костях" - самая трейдерская игра. Поганкин просил передать следующее - "всем играть, сцуко!" :)
cartoon

Феерическая философия программирования

На RSDN есть форум "философия программирования". Хочу провести экскурсию по этому феерическому месту. На примере одной дискуссии, в которой вы, в частности, сможете познакомиться с "призраком оперы" данного форума, и общей атмосферой этого места. Это, в сущности, весело. It's supposed to be entertainment. Хотя некоторые вопринимают это место, и зловещие события, происходящие в нем, чрезвычайно серьезно.

Итак, (вспоминаем основную тему "призрака оперы") Пам! Па-ра-ра-ра-ра-ра-ра-ра-а-а-а-ам!! Та-ра-а-а-а-ра-рам!!!

взгляд со стороны

Сухой остаток или нетленные ценности

А вот и мой пост. Как же такое пропустить:
Слякоть, тлен, и суета сует.

"Здесь звучало мнение, что якобы законы эволюции технологии не отличаются от науки.

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

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

И.А. Негодаев. Философия техники
http://polbu.ru/negodaev_engineeringphilo/

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

Вы сидите сейчас под виндой? Самому понятию PC, такому, как оно есть сейчас, вы обязаны в первую очередь лично Гейтсу, и тем раздолбаям из IBM, которые приняли решение собирать IBM PC на базе открытых компонент, отдав при этом ключевую компетенцию — разработку ОС, на сторону Гейтсу, с правами неограниченной продажи (долго потом волосы на жопе рвали, да поздно). Именно это стечение личностей и обстоятельств в определенный момент времени и определило появление открытого стандарта PC, широкого рынка OEM-производителей. И определило весь вектор развития технологий вычислительной техники на последующие десятки (!) лет.

Маленькая компания Intel, например, сейчас ведущий производитель процов (кто бы мог подумать об этом в 80-м году), а их кривая в дугу х86 сейчас является доминирующей архитектурой (на смех бы подняли тогда, если кто предположил). Задумайтесь об этом — вот он, принцип преемственности и инерционности в инженерии в действии. А ведь все могло бы быть совсем не так. Вся история техники — это личности, появившиеся в нужное время в нужном месте. Think again.

Что же касается более фундаментальных и общих законов развития технологии — читайте книгу. Там все написано. Сами поймете, насколько далеко все ушло от наивных рассуждений "по аналогии". Эта тема волнует людей уже сотню лет как минимум, и каждый инженер должен быть знаком со своим "родным" разделом философии, ИМХО. Это стыдно не знать. 

PS: Философы, блин 
PPS: Спасибо Дворкин, читая твои опусы я заставил себя ближе ознакомится с философией техники, а это уже кое-что. Чего и другим желаю."
cartoon

Моделирование динамики процесса разработки ПО

Стало ужасно модной темой последнее время.

из наших этой темой плотно занимается Байрам.
http://edu.it-online.ru/education/guru-academy/annakov_dyn/

да что Байрам, сам Йордан будет в сентябре с семинарами на эту тему в России,

http://edu.it-online.ru/education/guru-academy/yourdon_peopleware_wargames/index2.shtml

Ну и сам Том ДеМарко пишет об этом в своем "Deadline". Это совершенно замечательная книга, роман об управлении проектами, представитель редкого сейчас жанра "производственный раман". Вот помните хардкорные советские производственные фильмы? Вот это примерно то же самое :). И в одной из глав данной книги автор рассказывает про динамические модели Абдул-Гамида.

Идея в самом деле очень интересная. Основная посылка состоит в том, что интуиция, с одной стороны, слабо способна корректно предсказывать поведение сложной системы, однако, интуиция отлично работает касательно простых фактов. Что, если соединить это вместе? А именно, мы интуитивно оцениваем некоторые простые закономерности (скажем, зависимость эффективности работы команды от количества людей в ней), после чего - мы разрабатываем модель процесса, состоящую из вроде как простых и интуитивно понятных элементов (применяются водопроводные аналогии), таких как емкости с "водой", связанные "трубами" и "вентилями".

Collapse )
cartoon

Мощность языка

http://www.rsdn.ru/forum/message/2831858.1.aspx

Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, Klapaucius, Вы писали:

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

Т>Ну, про мощность уже выяснили. А по сопротивлению надо оценивать упругость языка.

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

I = U / R, P = I U

следовательно

R = U / I = U^2 / P

Ну вот, теперь мысль Клапауция как на ладони — сопротивление, оказываемое языком, пропорционально квадрату напряжения, которое требуется для того, чтобы думать и говорить на нем. Но, при этом, оно обратно пропорционально его мощности.

Метод оценки мощности по сопротивлению языка — это, безусловно, новое слово в инженерной науке.
cartoon

Об аспирантуре и кандидатских

Бурцев-сенсей (академик РАН, главный конструктор Эльбрус-2) сидел в своем кабинете, проверяя материалы для новой статьи. Глянул на часы: близится двенадцать. "Обязательно придет", подумал Бурцев, "Типаж такой, не может не прийти".

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

- Здравствуйте Всеволод Сергеич! А я к вам!
"Ну разумеется", подумал Бурцев.
- Здравствуй-здравствуй, Юра (имя вымышленное), - сердечно поприветствовал его Бурцев, - с чем пожаловал?
- Да вот, понимаете, Всеволод Сергеич, я тут кандидатскую защитил...
- Да, я еще раз тебя поздравляю! - с улыбкой сказал Бурцев. Он знал, что будет дальше.
- Надо бы, это...
- Что?
- Зарплату бы мне поднять, Всеволод Сергеич!
- А за что? - недоуменно спросил Бурцев.
- Но я ведь кандидат технических наук!
- Я не понял - ты от того что защитился - умнее что-ли стал? - удивился Бурцев-сенсей.

Тут бы сказать, как в таких историях полагается, что ученик немедленно достиг просветления, но не могу. Потому что словил ли Юра (имя вымышленное) просветление - неизвестно. Мое мнение - вряд ли. Сами понимаете - типаж такой.
cartoon

Об альтернативном методе оценки сроков (PERT Estimation sux)

Что такое PERT Estimation. Это элемент метода PERT, предназначенный для оценки сроков проекта. А именно, речь идет вот об этих формулах:


Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected
Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).
Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.
Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time).
TE = (O + 4M + P) ÷ 6

Метод берет тройную экспертную оценку сроков на вход, и выдает на выход
Pert Estimation = (O + 4M + P) ÷ 6
и
Pert Deviation = (P — O)/6

В литературе по управлению проектами рекомендуют суммировать Pert Estimation по задачам, чтобы получить прогноз итоговых трудозатрат. Также, там говорят, что формулы PERT аддитивны — типа вы суммируете O M P и применяете формулы PERT к ним.

Что в методе хорошо. Хорошо — это тройная оценка. При одинарной оценке вы не знаете, на что именно эксперт перезаложился, когда ее давал. А тут — тройная, все видно, и оптимистичная есть, и пессемистичная, никакой "тенденции к переоценке-недооценке", возникающей из манеры оценщика трактовать единственную оценку вы не увидите. Второе — по ширине интервала P — O вы увидите, насколько сама оценка достоверна, насколько оценщик в ней уверен.

Вроде-бы, здорово. Однако, после примерно 5-летней практики применения того метода, у меня появились вопросы:
Каков физический смысл PERT Deviation? Вот допустим, я хочу выдать на выходе коридор трудозатрат, и вероятность, что я в него впишусь. Как эта штука мне поможет?

Хорошая новость оказалась в том, что PERT Estimation основан на бета-распределении. Однако, дальше идут только плохие новости. А именно:
— формулы приближенные. Точного beta distribution они не дают, это так, нос к лаптю.
— В литературе упоминается благотворный эффект увеличенного количества единиц планирования - погрешности планирования взаимоуничтожаются и повышается точность плана. Так вот, чтобы учесть тот эффект, формулы PERT нельзя трактовать как аддитивные, как пишут в книгах. Потому, среднеквадратичное отклонение для независимых задач надо перед суммированием возводить в квадрат.
— А после этого ответить на вопрос о том, с какой вероятностью я впишусь в срок, скажем, PERT Estimation + PERT Deviation, уже не так просто, потому как наш бета дистрибьюшен (и так приближенный) безнадежно испорчен суммированием. И стал, благодаря ценральной предельной теореме, чем-то средним между гауссовским и бета-распределением.

Короче, что я хочу и не могу получить с PERT Estimation. Да очень простую штуку, вроде этого:
С вероятностью 85% проект завершится в 4 месяца, с вероятностью 98% — 4,5 месяца. При этом, метод должен учитывать независимость задач. Причем, я хочу понимать, как оценка получается, это должно быть просто и прозрачно. И еще, желательно, иметь прямое отношение к теории вероятностей, мне так спокойнее.

Да, раз уж мы взялись за метод, то надо учесть и практику применения, по которой выходит, что людей напрягает средняя оценка. Им проще всего ответить на два вопроса касательно сроков:
а) Точно не уложусь
б) Успею 100%
Причем, разница между этими оценками может быть большой. Метод должен работать все равно, нас это не должно волновать. Итак, приступим.

За основу возьмем гауссовское нормальное распределение. Все равно распределение суммы случайных величин сходится именно к нему (т.е. мы его все равно получим в конце концов, независимо от нашего желания), так что не будем никого обманывать. Да и свойства у него приятные. Вот оно:
http://en.wikipedia.org/wiki/Normal_distribution


На вход будем брать две оценки, как договорились. Внимательно глядя на график нормального распределения, понимаем, что
Точно не уложусь = L = ME — 2*Sigma (вероятность, что проект таки закончится раньше — 2.2%), где ME - это матожидание.
Успею 100% = H = ME + 2*Sigma (Вероятность завершения до этого срока = 97,8%)
То есть

ME = ( L + H ) / 2.
Sigma = ( H - L ) / 4.

Можно обработать и тройную оценку, как в PERT Estimation. Пока я не понимаю, как лучше - две или три. Мне кажется, в пользу тройной оценки говорит то, что имея центральную оценку, человек будет меньше ошибаться с пессимистичной оценкой. Если брать три оценки, то делается обработка, очевидно так:

ME = ( L + 2*M + H ) / 4.
Sigma = ( H - L ) / 4.

Центр "колокольчика" нормального распределения будет находится в этом случае посередине между центром ( H - L ) / 2 и оценкой M. Мне кажется, достаточно разумно. Уж по крайней мере лучше, чем в PERT, там центральная оценка идет с весом 4 и фактически полностью забивает граничные оценки.

Ну вот, дальше дело техники.

Для суммы задач, ME = Sum( ME[i ], i = 1..n ), это понятно. А вот насчет сигмы все сложнее.

В предположении, что прогнозы продолжительности задач (случайные величины) у нас независимы, мы имеем сигму

S = sqrt( Sum( S[i]^2, i = 1..n )).

Однако, на практике не все прогнозы продолжительности можно трактовать как независимые. Почему так — да потому, что при недооценке сложности одного крупного модуля (что легко сделать на раннем этапе, когда нет детального дизайна) вверх дружно полезут длительности всех задач, к нему относящихся. Поэтому, надо разделять зависимые прогнозы от независимых, и трактовать их по разному - для зависимых прогнозов надо суммировать сигму простым образом, не через квадраты.

Короче говоря — какие задачи у нас еще будут зависимы по длительностям. Фазы разаботки одного блока/модуля. Предположим, их 4 — требования, дизайн/архитектура, разработка, отладка/доводка. Пусть мы завели четыре таких задачи, и их оценили. Так как они относятся к одному модулю, то в случае недооценки сложности этого модуля увеличатся продолжительности всех четырех задач одновременно. Другими словами, случайные величины сроков этих задач зависимы, и для них надо просто суммировать сигму.

Отсюда следует, что независимыми можно считать только агрегатные оценки по независимым по функциональности модулям и фрагментам системы (включая все активности по их разработке). Декомпозицию крупной задачи наугад тоже нельзя трактовать как набор независимых задач. Задача интеграционного тестирования будет _зависимой_ с предыдущим этапом. Вообще, очень похоже, что зависимость задач окончание-начало сигнализирует о зависимости прогнозов сроков работ. Надо по реальным планам проверить.

Что это означает для планирования. Для аккуратного обращения с сигмой, надо рассматривать задачи в виде иерархии, и вводить разные правила сумирования для груповых задач и для подзадач.
1) Для этапов работ (когда этап означает фазу разработки) — надо выполнять прогноз простым суммированием исходных оценок.
2) Для независимых по реализуемым функциям работ внутри этапа, которые могут быть выполнены в параллель — суммирование через квадраты по изложенным правилам.
3) Для итераций (когда этап реализует добавочную функиональность, независимую или слабозависимую от результатов предыдущей итерации) — надо также суммировать через квадраты.

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

Однако, что мы все-таки можем получить в результате нашего нового метода. А вот что:
С вероятностью 84,2% (ладно, не будем морочить голову, и так все приближенное — пусть будет 85%), или если по человечески — то "скорее всего" у меня трудозатраты уложатся в M + S
И с вероятностью 97,8% (лана, лана, пусть будет 98%), то есть "наверняка", они не превысят M + 2*S.

Вот, теперь наконец у меня есть точный (насколько это вообще возможно) метод оценки трудозатрат для заказных проектов fixed cost. И я могу предсказывать свою маржу на раннем этапе, и по человечески, без жевания соплей, отвечать на вопросы о рисках. Может и не точно, как в аптеке, но по крайней мере буду знать, что говорю. Чего и желаю всем последователям вотерфола , ну и agile тоже. :) Короче, проверим метод на практике.