Всё зависит от того, что это за 2000+ строк.

Если это нормально побитый на методы класс + куча каких-нибудь геттеров/сеттеров, то и ладно (хоть и многовато на мой вкус, но читабельно).

Но реальность такова, что чаще всего в легаси-проектах в этих 2000+ строках полтора метода, которые занимаются всем и дёргают всё возможное (и SQL через heredoc, и строковые подстановки вместо шаблонов, и глобальные переменные/синглтоны/реестры, и т.д). Такое разбирать и поддерживать действительно сложно.

Так вроде же упомянуто в последнем листинге:

double Weibull(double l, double k) {
    return l * pow(Exponential(1), 1.0 / k);
}

Или вы о том, что есть способ заметно лучше?

Не являюсь специалистом по теме, даже не владею всем понятийным аппаратом в полной мере, но всё же.

На первый взгляд, в данной статье указан в явном виде базовый примитив, который уже давно используется для определения безопасности криптографических примитивов. А именно, схема доказательства некоторых свойств стойкости алгоритмов с точки зрения неразличимости для некоторого advisor (советника) выхода алгоритма и случайного выхода, но расширенный также на выход другого алгоритма.

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

Но можете объяснить, что ещё стоит понять из вашей статьи, на что обратить внимание? Думаю, многие на данном ресурсе будут ждать конкретной схемы обфускации, которая решит все их возможные проблемы. Можете ли вы для них подчеркнуть, есть ли готовые практические алгоритмы, а также какие теоретические задачи iO уже решила, которые были не решены раньше?

Главное — выбрать одним из слов «делаем»

Хм, интересная вещь. Но она просто добавляет немного сахара к вызовам или я что-то упускаю?
Кстати, github.com/phpspec/prophecy не смотрели?

Всё к лучшему, Hello World уже как-то поднадоел ;) Но да, риск превратить пару строчек в монстра есть всегда.

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

Пока не умеет, никаких типов для длинных чисел там нет. Тут ведь всё от популярности и необходимости зависит, может, в будущем и вырастет до уровня GMP, но только если кому-нибудь это будет нужно на ноде.

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

Все почему-то смотрят на использование в браузере. Однако, мне кажется, что даже по докам основной юзкеис — Node.js на сервере. С производительностью, думаю, со временем будет лучше, пока важно, чтобы был какой-то удобный и общий интерфейс доступа к функциям, а там уже народ подтянется и допилит не оптимальные решения.

Потому же, почему в свое время гламурные кнопки и fage-эффекты назывались AJAX :) А если серьезно, то тренд просто расширяет свои термины на около-трендовую среду и сейчас почти все, что хранит данные не на локале, называется облаком.

Пожалуй, зря я начал комментарий с личного мнения… Просто специфика работы не моя, а на таком уровне, как описано в статье, про Intel Cilk Plus я уже знаю. Однако, это нисколько не умаляет достоинств статьи. Хотелось бы еще увидеть топики автора про другие аспекты работы с распараллеливанием программ. Особенно, если они будут с такими же доходчивыми и правильными объяснениями.

Скажу честно: мне было не очень интересно читать про Intel Cilk Plus. В каком-то виде я это знал. Но вот так подробно и понятно разобранный материал на тему гомоморфизмов — за это большой плюс. Спасибо.

А если Вы спрашиваете про отличия, например, :after от ::after, то тут все просто. В спецификации CSS2.1 использовалось одинарное двоеточие для псевдо-элементов, а в CSS3 стали применять двойное, чтобы отделить псевдо-элементы от псевдо-классов.

С одинарного двоеточия ":" начинаются псевдо-классы, например, a:hover. То есть, это неявный класс элемента a. Двойное двоеточие "::" — это псевдо-элементы, например, a::before. То есть, это неявный элемент, которого нет в разметке, но мы его как-бы создаем через css (точнее, браузер понимает, это мы выделяем что-нибудь в элемент).

Подробнее про разные псевдо-элементы и псевдо-классы лучше читать в справочниках. Для начального ознакомления подойдет htmlbook.ru.

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

Зачем это нужно? Мне кажется, что это может пригодиться для оценки полного времени работы над изменениями.

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

Насчет IBM — да, видимо, они используют свои оценки для процента мало/много исправляемых модулей. И их коэффициенты будут работать для данного проекта и данной команды разработчиков/тестеров.

Насчет выкладок. Смотрим статью, внимание — ключ к пониманию :)

Nиспр = 2*( 0.9*Nнов. мод. + 0.15*Nстар. мод.) + 23*( 0.15*Nнов. мод. + 0.06*Nстар. мод.)

340.2 = 2*( 0.9*20         + 0.15*140        ) + 23*( 0.15*20         + 0.06*140        )
      = 2*( 18             + 21              ) + 23*( 3               + 8.4             )

Да, тут мы по собранным ранее коэффициентам угадываем, сколько и каких исправлений нужно будет сделать.

В статье все есть, но продублирую и поясню, так как это основная идея данного метода:

… в силу равновероятности нахождения любой из ошибок, любое случайным образом выбранное подмножество из N можно рассматривать как аппроксимацию всего множества N. Это значит, что если первая группа обнаружила 10% всех ошибок, она должна обнаружить примерно 10% из любого случайным образом выбранного подмножества.

В качестве такого случайным образом выбранного подмножества возьмём множество ошибок, найденных второй группой. Доля всех ошибок, найденных первой группой, равна N1/N. Доля ошибок, найденных первой группой среди тех ошибок, которые были найденны второй группой, равна N12/N2.

То есть, первая команда из N ошибок находит N₁, это ее «продуктивность».
Предполагаем, что «продуктивность» этой команды одинакова для любого тестирования. В частности, они тестировали то же, что и вторая команда. То есть, они нашли из N₂ ошибок, которые там точно есть, N₁₂ штук.
Получаем указанную пропорцию: N₁/N = N₁₂/N₂.

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

Все верно, в Википедии подробно все написано.

Но я проголосовал за первый вариант (круг=окружность как подкласс эллипса) и сейчас объясню, почему.

LSP при использовании этого способа наследования нарушается только в том случае: если объекты наших классов мутабельны. Однако, в формулировке задачи этого нет, а в моей практике нужны были именно подобные иммутабельные классы => для неизменяемых окружностей и эллипсов подходит первый вариант. Конечно, в реальных задачах это может быть часто не так и в каждом случае нужно выбирать отдельно.

Да, и этот многочлен не менее красив, чем теоремы Матиясевича. Тоже Сизого читали?)
Это я к тому, что интересующимся теорий чисел не помешает эта книга: Сизый С. В. Лекции по теории чисел.