Я очень порекомендую вам premake (среди тулзов cmake, qmake, premake он мне понравился больше всего). Хотя последняя версия вышла 16 ноября 2010, так что, возможно, он не очень живой.
Мне кажется, этого нельзя делать. Потому что a и b * c_1 — это настоящие вероятности разных измерений 0 и 1 на том этапе эксперимента, которые не надо дополнительно нормировать. И если их квадраты модулей в сумме не равны единице, то где-то есть ошибка, например, какой-то исход эксперимента не учитывается.
" еще могу сказать, что в Европе аспиранты получают в несколько раз больше" Это не так) Схема ровно такая же, как в США--вам платят ровно столько, чтоб вы ничего не могли накопить.
Сам я делаю PhD в Германии. Начал я его делать в одном из институтов общества Макса Планка (Институт динамики сложных технических систем в Магдебурге), и там мне платили 900 евро. Сейчас я переехал вместе с профессором в город Марбург, и тут мне платят 1100 евро (это уже после вычета налогов, мед страховки и т.п., исходная сумма--1700 евро, это тоже полставки). Аренда жилья--300-350 евро в месяц, раз в семестр надо платить за студенческий 300 евро. Домой иногда хочется слетать (тут этот соблазн намного сильнее).
В некоторых странах типа Дании, Швеции, Швейцарии можно услышать о стипендии в 3000 евро в месяц, но, насколько я знаю, обычно это тоже полставки, из них 1000 уйдет на налоги, а остальных хватит ровно на прожить (потому что все намного дороже). Так что не обольщайтесь насчет Европы.
А, я просто не осознал, что именно вас смущало. Тогда, как я и говорил, применимость модели определяется целями модели и контекстом применения. А самый простой способ улучшить оценку--помимо мат ожидания учитывать еще и дисперсию.
Виноват, перепутал с 4 возможными исходами. Да, в комментарии выше везде имелось в виду 2 проекта.
Да, значения 55 млн не будет никогда, но средняя прибыль от 100000 запусков пар будет равна примерно 55 млн * 100000. Убедитесь сами: 1/4--вероятность получения каждого из 4 исходов (0, 10, 100, 110), тогда средняя прибыль-- 100 000 / 4 * 0 + 100 000 / 4 * 10 + 100 000 / 4 * 100 + 100 000 / 4 * 110 = 100 000 / 4 * (0 + 10 + 100 + 110) = 100 000 * 55. То есть мат ожидание дискретных распределений может отличаться от каждого из значений распределения.
Мне кажется, что в статью можно добавить интерпретацию формул и сущностей:
Матрица--показывает все комбинации выполнения проектов. Коэффициенты a_ij--индикатор выполнения проекта j в комбинации i.
Формула 2--вычисляет число успешных проектов в комбинации i.
Формула 3--вычисляет вероятность выполнения комбинации i (мне кажется, там не хватает скобок, и ее можно переписать проще: П [ a_ij * p_j + (1 — a_ij ) * (1 — p_j) ] ).
Формула 4--вычисляет вероятность выполнения любой комбинации проектов с заданным числом успешных
Действие номер 2 (в списке перед графиком)--вычисляет вероятность выполнения любой комбинации проектов с числом успешных проектов меньшим или равным данному (к нему лучше бы добавить формулу, мне кажется) (мол, с вероятностью 65% мы выполним 4 и менее проекта)
Еще непонятно, откуда взялись даты на графике (видимо, это какие-то средние/максимальные сроки завершения по комбинациям проектов).
Комментарий по поводу: «При этом, как я полагаю, полагаются на закон больших чисел, когда считается, что для достаточно большой выборки эмпирическое среднее будет стремиться к теоретическому среднему». Мне кажется, примененимость формулы 1 зависит от контекста. Она означает, что если вы запустите мысленно эти 4 проекта очень-очень много раз, то средняя прибыль (мат ожидание) будет равна 55 млн. В каких-то приложениях именно этот ее смысл может быть полезен.
Действительно, закон больших чисел оправдывает ее применение для большого числа проектов. Кроме того, ее можно применять, если вы обеспечиваете стат. достоверность во времени и/или пространстве: запускаете именно эту четверку проектов одновременно во многих регионах (если вы FMCG company) или много лет подряд в течение длительного времени.
В общем-то, среднюю прибыль по однократному запуску четырех проектов она тоже оценит верно, только она скроет огромную дисперсию оценки. Поэтому в случае 4 проектов можно оперировать двумя величинами--мат ожиданием и дисперсией. А лучше всего просто начертить полное распределение (в конце концов, статистические моменты--попытка описать в нескольких числах все распределение, и полностью можно это сделать лишь бесконечным числом моментов).
Расскажу о своем опыте: в силу исторических причин JS ресурсы на проекте были локализованы в JS-файлах (через json, обычные словари через нативные яваскриптовые объекты)--это вполне хороший подход. В силу других исторических причин на проекте было много .resx ресурсов. Кроме того, (как я писал, это правильно) было принято решение вендорам локализации отправлять .resx.
Поэтому мы использовали такой подход:
1. переведенные файлы хранили в svn
2. на build сервере, в рамках continuous integration, во время билда все .resx файлы копировались в специальную папочку
3. все js файлы конвертились в resx и складывались в эту же папочку
4. в процессе билда для всех переводов, что лежат в svn те resx файлы, что получены из js, конвертились обратно в js и складывались в релизную папку
5. все остальные resx файлы собирались в сателлитные сборки (автоматически, на билд сервере, по скриптам, сгенерированным автоматически на основе файлов проекта)
То есть для JS схема такая: JS->[build]->.resx->[localize]->localized resx->[send to developers, add to svn]->[build]->JS
При проектировании локализации разработчики часто упускают один очень важный момент: у локализации через ресурсы, несмотря на все ее недостатки, есть одна киллер-фича--поскольку это долгое время было рекомендованным решением от MS, вендоры локализации поддерживают формат resx, и требуют намного меньше денег за перевод, если вы им отправляете весь текст в файлах ресурсов.
Чтоб было понятнее: у вендоров локализации (вот этого, например) есть свои специальные тулзы, которые понимают многие форматы файлов, и позволяют сильно облегчить процесс локализации--например, распределить перевод на разных специалистов, хранить в базе все переводы фраз для данного проекта (и тогда, если какая-то фраза была уже встречалась, подсказать ее переводчику и т.п.).
Так вот, эти тулзы не поддерживают никакие кастомные файлы, они поддерживают .resx. Лично мне тоже очень не нравится локализация через satellite assemblies (она отвратительна, в общем-то), но на крупных проектах, где локализация стоит очень дорого, resx--единственный выбор.
Правда, можно спроектировать систему так, что в приложении локализация происходит не через satellite assemblies, но сами тройки «ключ-оригинал-перевод» хранятся в resx. Или можно сделать двухступенчатый процесс: локализацию хранить как угодно (хоть в базе), и написать конвертер в resx для переводчиков, и обратный конвертер, чтоб импортировать перевод назад в базу.
Так или иначе, не забывайте про стандарты отрасли локализации!
Это, мне кажется, совсем не очевидно. Есть механизмы уширения спектральных линий, применимые и к радиосигналам, и различные виды дисперсий (хотя, конечно, в открытом космосе будет участвовать только материальная дисперсия). Конечно, может быть, плазменные облака так разреженны, что не будут влиять на уширение спектральных линий. С другой стороны, могут появиться специфические механизмы дисперсии, типа разного отклонения фотонов с разной энергией (т.е. частотой) в гравитационных линзых и т.п.
То есть удаленная цивилизация может увидеть сигнал с определенной шириной спектра, но сказать наверняка «ух ты, какие сложные сигналы. Наверное, это телепередача» не сможет.
Конечно, тот факт, что радиосигналы с посланием внеземным цивилизациям отправлялись в открытый космос, намекает, что расчеты были сделаны, и так статься не может, но все-таки это неочевидно.
Я думаю, что spin crossover molecules--это вовсе не «вращения пересекающихся молекул», а что-то типа молекулы с кроссовером спина. Спин здесь--это специальная характеристика квантовой системы, а spin crossover--специальный эффект. Правда, как это переводится на русский, я не знаю.
Да, вполне может быть, что вы правы. Правда, непонятно, почему слух работает через разложение на гармоники (в смысле комплексные экспоненты; например, можно разлагать по любому другому полному набору функций, даже не ортогональному; функциям Бесселя, например).
Но вот несколько идей:
1. гармоники наиболее оптимальны в том смысле, что для случайного сигнала отклонение функции, восстановленной по конечному числу обертонов от исходного будет минимальным именно для гармоник
2. колебания осциллятора в потенциальной яме любой формы в первом приближении можно представить как колебания осциллятора в яме параболической формы (разлагая потенциал в ряд Тейлора, члена первой степени там не будет, если яма симметричная), а это--гармонические колебания, и их собственные функции--как раз гармоники, то есть это самые типичные звуки
По поводу октав, диссонансов и консонансов можете глянуть вот что: 1, 2, 3.
Октаве соответствует соотношение базовых частот 1:2, терции 5:4, доминанте 3:2. Это значит, что при звучании тоники и доминанты каждый третий обертон тоники (в разложении Фурье) и каждый второй доминанты будут совпадать. То есть звуки будут максимально гармонировать и максимально усиливать друг друга. Мне кажется, взаимное усиление уже может быть достаточным условием для формирования эволюционного предпочтения.
Для верстальщика-быдлокодера не предлагаю. Для .Net инженера, работающего по agile, с вертикальной разработкой, который делает весь стек фичи--от базы данных до UI (js/html/css)--да, это musthave, по-моему. Точнее, VS+решарпер для .Net инженера это musthave, а функционал WebStorm--это весьма приятный бонус.
Мне кажется, его в любом случае не стоит использовать, а как-то по-другому решать проблемы, где подходит этот метод (как с обработчиком ready). Такое решение--это дурной запах (точнее, отвратительное зловоние) того, что что-то не так с архитектурой.
Сам я делаю PhD в Германии. Начал я его делать в одном из институтов общества Макса Планка (Институт динамики сложных технических систем в Магдебурге), и там мне платили 900 евро. Сейчас я переехал вместе с профессором в город Марбург, и тут мне платят 1100 евро (это уже после вычета налогов, мед страховки и т.п., исходная сумма--1700 евро, это тоже полставки). Аренда жилья--300-350 евро в месяц, раз в семестр надо платить за студенческий 300 евро. Домой иногда хочется слетать (тут этот соблазн намного сильнее).
В некоторых странах типа Дании, Швеции, Швейцарии можно услышать о стипендии в 3000 евро в месяц, но, насколько я знаю, обычно это тоже полставки, из них 1000 уйдет на налоги, а остальных хватит ровно на прожить (потому что все намного дороже). Так что не обольщайтесь насчет Европы.
Да, значения 55 млн не будет никогда, но средняя прибыль от 100000 запусков пар будет равна примерно 55 млн * 100000. Убедитесь сами: 1/4--вероятность получения каждого из 4 исходов (0, 10, 100, 110), тогда средняя прибыль-- 100 000 / 4 * 0 + 100 000 / 4 * 10 + 100 000 / 4 * 100 + 100 000 / 4 * 110 = 100 000 / 4 * (0 + 10 + 100 + 110) = 100 000 * 55. То есть мат ожидание дискретных распределений может отличаться от каждого из значений распределения.
Матрица--показывает все комбинации выполнения проектов. Коэффициенты a_ij--индикатор выполнения проекта j в комбинации i.
Формула 2--вычисляет число успешных проектов в комбинации i.
Формула 3--вычисляет вероятность выполнения комбинации i (мне кажется, там не хватает скобок, и ее можно переписать проще: П [ a_ij * p_j + (1 — a_ij ) * (1 — p_j) ] ).
Формула 4--вычисляет вероятность выполнения любой комбинации проектов с заданным числом успешных
Действие номер 2 (в списке перед графиком)--вычисляет вероятность выполнения любой комбинации проектов с числом успешных проектов меньшим или равным данному (к нему лучше бы добавить формулу, мне кажется) (мол, с вероятностью 65% мы выполним 4 и менее проекта)
Еще непонятно, откуда взялись даты на графике (видимо, это какие-то средние/максимальные сроки завершения по комбинациям проектов).
А в целом спасибо за статью!
Действительно, закон больших чисел оправдывает ее применение для большого числа проектов. Кроме того, ее можно применять, если вы обеспечиваете стат. достоверность во времени и/или пространстве: запускаете именно эту четверку проектов одновременно во многих регионах (если вы FMCG company) или много лет подряд в течение длительного времени.
В общем-то, среднюю прибыль по однократному запуску четырех проектов она тоже оценит верно, только она скроет огромную дисперсию оценки. Поэтому в случае 4 проектов можно оперировать двумя величинами--мат ожиданием и дисперсией. А лучше всего просто начертить полное распределение (в конце концов, статистические моменты--попытка описать в нескольких числах все распределение, и полностью можно это сделать лишь бесконечным числом моментов).
Поэтому мы использовали такой подход:
1. переведенные файлы хранили в svn
2. на build сервере, в рамках continuous integration, во время билда все .resx файлы копировались в специальную папочку
3. все js файлы конвертились в resx и складывались в эту же папочку
4. в процессе билда для всех переводов, что лежат в svn те resx файлы, что получены из js, конвертились обратно в js и складывались в релизную папку
5. все остальные resx файлы собирались в сателлитные сборки (автоматически, на билд сервере, по скриптам, сгенерированным автоматически на основе файлов проекта)
То есть для JS схема такая: JS->[build]->.resx->[localize]->localized resx->[send to developers, add to svn]->[build]->JS
Чтоб было понятнее: у вендоров локализации (вот этого, например) есть свои специальные тулзы, которые понимают многие форматы файлов, и позволяют сильно облегчить процесс локализации--например, распределить перевод на разных специалистов, хранить в базе все переводы фраз для данного проекта (и тогда, если какая-то фраза была уже встречалась, подсказать ее переводчику и т.п.).
Так вот, эти тулзы не поддерживают никакие кастомные файлы, они поддерживают .resx. Лично мне тоже очень не нравится локализация через satellite assemblies (она отвратительна, в общем-то), но на крупных проектах, где локализация стоит очень дорого, resx--единственный выбор.
Правда, можно спроектировать систему так, что в приложении локализация происходит не через satellite assemblies, но сами тройки «ключ-оригинал-перевод» хранятся в resx. Или можно сделать двухступенчатый процесс: локализацию хранить как угодно (хоть в базе), и написать конвертер в resx для переводчиков, и обратный конвертер, чтоб импортировать перевод назад в базу.
Так или иначе, не забывайте про стандарты отрасли локализации!
Более того, ОТО наверняка неверна, потому что не согласуется с квантовой механикой (хоть и неплохо работает в больших масштабах).
И даже лучше, ОТО не опровергает существование "кротовых нор".
То есть удаленная цивилизация может увидеть сигнал с определенной шириной спектра, но сказать наверняка «ух ты, какие сложные сигналы. Наверное, это телепередача» не сможет.
Конечно, тот факт, что радиосигналы с посланием внеземным цивилизациям отправлялись в открытый космос, намекает, что расчеты были сделаны, и так статься не может, но все-таки это неочевидно.
Тем не менее, спасибо за статью.
Но вот несколько идей:
1. гармоники наиболее оптимальны в том смысле, что для случайного сигнала отклонение функции, восстановленной по конечному числу обертонов от исходного будет минимальным именно для гармоник
2. колебания осциллятора в потенциальной яме любой формы в первом приближении можно представить как колебания осциллятора в яме параболической формы (разлагая потенциал в ряд Тейлора, члена первой степени там не будет, если яма симметричная), а это--гармонические колебания, и их собственные функции--как раз гармоники, то есть это самые типичные звуки
Октаве соответствует соотношение базовых частот 1:2, терции 5:4, доминанте 3:2. Это значит, что при звучании тоники и доминанты каждый третий обертон тоники (в разложении Фурье) и каждый второй доминанты будут совпадать. То есть звуки будут максимально гармонировать и максимально усиливать друг друга. Мне кажется, взаимное усиление уже может быть достаточным условием для формирования эволюционного предпочтения.