Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

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

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

Мы сами (наша команда) потратили на видеоигры тысячи часов своих жизней. И сейчас мы используем накопленный опыт, создавая Uplift — игровой тренажер интеллекта.

Здравствуй, Хабр!

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

• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая, шестая и седьмая
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• Подкаст в iTunes
• Плейлист на YouTube
• Форум курса

Первая лекция: Введение в JavaScript, немного истории, числа (тут есть ошибка: функция toFixed округляет значения).



Остальное – под катом.

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

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

Если кратко, то как ООП, так и ФП неэффективны, если доходить в их использовании до крайности. Крайностью в ООП считается идея о том что “все что угодно является объектом” (чистое ОП). Крайностью для ФП можно рассматривать чистые функциональные языки программирования.

Итак, Вы собираетесь создать новый [] функциональный, [] императивный, [] объектно-ориентированный, [] процедурный, [] стековый, [] мультипарадигменный, [] быстрый, [] статически-типизированный, [] динамически-типизированный, [] чистый, [] богатый, [] не-искусственный, [] наглядный, [] простой для новичков, [] простой даже для не-программистов, [] абсолютно непостижимый язык программирования.

Не получится. И вот почему.

Некоторые из вас, вероятно, видали на просторах сети эту задачку: какое число продолжает следующий ряд?

Предлагался такой очевидный правильный ответ:

Для тех, кому неочевидно, как он получен, предлагалось объяснение. Пусть (ну и 1 при x = 0, хотя неважно). Тогда каждый член ряда — это значение следующего интеграла в цепочке:

Пока всё идёт хорошо, но тут внезапно:

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

Сегодня предложу Вашему вниманию симпатичный алгоритм, который хоть и придумали совсем недавно (11 лет назад), но «прототипом» послужило счётное устройство с трёхтысячелетней историей.

Этим летом в Москве прошла первая летняя школа по биоинформатике. В ней приняло участие более 100 человек, которые приехали из различных уголков России и СНГ и были разделены на два потока: «информатики» и «биологи». Организовал мероприятие Институт биоинформатики в сотрудничестве с СПбАУ РАН, МГУ, ИППИ РАН и программой GameChangers.

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

Если вы впервые слышите про биоинформатику, то советую в первую очередь посмотреть вводную лекцию Аллы Лапидус, которая расставит всё на свои места. Сейчас Алла занимает ведущие позиции в центре геномной биоинформатики СПбГУ и в лаборатории алгоритмической биологии СПбАУ РАН, а ранее долгое время руководила геномными проектами в DOE Joint Genome Institute (Калифорния).



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

Вступление

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

Начальное описание

Алгоритм Ахо-Корасик реализует эффективный поиск всех вхождений всех строк-образцов в заданную строку. Был разработан в 1975 году Альфредом Ахо и Маргарет Корасик.
Опишем формально условие задачи. На вход поступают несколько строк pattern[i] и строка s. Наша задача — найти все возможные вхождения строк pattern[i] в s.

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

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

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

Для начала терминология. Пентаграммой называют совокупность всех диагоналей пятиугольника, в случае гексаграммы — это уже не все диагонали, а только те, которые соединяют непротивоположные вершины шестиугольника. Во обоих случаях эти вершины идут через одну друг от друга. Например, если вершины пятиугольника перенумеровать (0, 1, 2, 3, 4), то пентаграмма — совокупность линий (0, 2), (1, 3), (2, 4), (3, 0), (4, 1). Гексаграмма (0, 1, 2, 3, 4, 5), соответственно, является совокупностью линий (0, 2), (1, 3), (2, 4), (3, 5), (4, 0), (5, 1). Нули в качестве начальной точки взяты не случайно и не как дань програмистскому мышлению, удобство этого обозначения я опишу ниже. Линии, образующие полиграмму, я буду называть ребрами. Вершинами полиграммы я буду называть вершины исходного полигона, а не все точки пересечения ребер.

Привет!

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

Равновесие между работой и жизнью слишком важно, чтобы доверить заботу о нем вашему работодателю, утверждает Найджел Марш. Выступая на конференции TEDxSydney, Найджел Марш дает своё представление об идеальном дне, в котором гармонично сочетаются время для семьи, личных нужд и работы — и предлагает будоражащую идею о том, как этого можно достичь. Основная идея доклада в том что побеждает не тот, у кого на момент смерти больше денег в кошельке, а тот, кто пришел к осмысленной идее о том, как должна выглядеть хорошо сбалансированная жизнь. Лично я в этом докладе увидел много полезного для себя, рекомендую к просмотру, %username%.



Для тех кто любит читать, а не смотреть под катом сокращенная текстовая версия.

Pipe — что это?

Pipe (конвеер) – это однонаправленный канал межпроцессного взаимодействия. Термин был придуман Дугласом Макилроем для командной оболочки Unix и назван по аналогии с трубопроводом. Конвейеры чаще всего используются в shell-скриптах для связи нескольких команд путем перенаправления вывода одной команды (stdout) на вход (stdin) последующей, используя символ конвеера ‘|’:

cmd1 | cmd2 | .... | cmdN

Например:

$ grep -i “error” ./log | wc -l
43

grep выполняет регистронезависимый поиск строки “error” в файле log, но результат поиска не выводится на экран, а перенаправляется на вход (stdin) команды wc, которая в свою очередь выполняет подсчет количества строк.

Логика

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

Размер буфера начиная с ядра версии 2.6.11 составляет 65536 байт (64Кб) и равен странице памяти в более старых ядрах. При попытке чтения из пустого буфера процесс чтения блокируется до появления данных. Аналогично при попытке записи в заполненный буфер процесс записи будет заблокирован до освобождения необходимого места.
Важно, что несмотря на то, что конвейер оперирует файловыми дескрипторами потоков ввода/вывода, все операции выполняются в памяти, без нагрузки на диск.
Вся информация, приведенная ниже, касается оболочки bash-4.2 и ядра 3.10.10.

Простой дебаг

Утилита strace позволяет отследить системные вызовы в процессе выполнения программы:

$ strace -f bash -c ‘/bin/echo foo | grep bar’
....
getpid() = 13726                   <– PID основного процесса
...
pipe([3,  4])                       <– системный вызов для создания конвеера
....
clone(....) = 13727                <– подпроцесс для первой команды конвеера (echo)
...
[pid 13727] execve("/bin/echo",  ["/bin/echo",  "foo"],  [/* 61 vars */] 
.....
[pid 13726] clone(....) = 13728    <– подпроцесс для второй команды (grep) создается так же основным процессом
...
[pid 13728] stat("/home/aikikode/bin/grep",   
...

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

Эта статья родилась как логическое продолжение пятничного поста о методе Бутстрапа, а особенно, комментариев к нему. Не защищая метод Бутстрапа, стоит уделить внимание методам Монте-Карло. Здесь я хочу поделиться своим опытом применения Монте-Карло в одной из своих практических задач, а также обоснованием законности этого применения.

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

Я был крайне удивлён, найдя мало статей про динамическое программирование (далее просто динамика) на хабре. Мне всегда казалось, что эта парадигма довольно сильно распространена, в том числе и за пределами олимпиад по программированию. Поэтому я постараюсь закрыть этот пробел своей статьёй.

# Весь код в статье написан на языке Python

Основы

Пожалуй, лучшее описание динамики в одно предложение, которое я когда либо слышал:

Динамическое программирование — это когда у нас есть задача, которую непонятно как решать, и мы разбиваем ее на меньшие задачи, которые тоже непонятно как решать. (с) А. Кумок.

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

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

Итак, алкотестер. Он же breathalyzer. Это задачка snack-сложности по классификации facebook, т.е. по их меркам она совсем не сложная. Что не помешало мне потратить на её решение добрых пару недель(отчасти из-за принципиального желания решить её на Ruby). Эту задачу я делал второй по-очереди, и именно она натолкнула меня на основную идею, побудившую меня прикладывать кучу усилий для поиска решения. А идея была в следующем — я не умею программировать…

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

В статистике тоже есть нечестный метод, который позволяет получить примерный ответ на многие практические вопросы без анализа, грубой компьютерной силой: бутстрап (англ. bootstrap). Придумал и опубликовал его в 1979 году Брэдли Эфрон.

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

Нормальное распределение (распределение Гаусса) всегда играло центральную роль в теории вероятностей, так как возникает очень часто как результат воздействия множества факторов, вклад любого одного из которых ничтожен. Центральная предельная теорема (ЦПТ), находит применение фактически во всех прикладных науках, делая аппарат статистики универсальным. Однако, весьма часты случаи, когда ее применение невозможно, а исследователи пытаются всячески организовать подгонку результатов под гауссиану. Вот про альтернативный подход в случае влияния на распределение множества факторов я сейчас и расскажу.