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

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

Насколько это соответствует истине?

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

Алгоритм Левенберга-Марквардта прост. Алгоритм Левенберга-Марквардта эффективен.

А еще о нем говорят, что он где-то посередине между градиентным спуском и методом Ньютона, что бы это ни значило. Ну, с методом Ньютона и его связью с градиентным спуском вроде как разобрались. Но что имеют в виду когда произносят эту глубокомысленную фразу? Попробуем слегка подразобраться.

О методах численной оптимизации написано много. Это и понятно, особенно на фоне тех успехов, которые в последнее время демонстрируют глубокие нейронные сети. И очень отрадно, что хотя бы часть энтузиастов интересуется не только тем, как забомбить свою нейросеточку на набравшей в этих ваших интернетах популярность фреймворках, но и тем, как и почему все это вообще работает. Однако мне в последнее время пришлось отметить, что при изложении вопросов, связанных с обучением нейросетей (и не только с обучением, и не только сетей), в том числе на Хабре, все чаще впроброс используется ряд “хорошо известных” утверждений, справедливость которых, мягко говоря, сомнительна. Среди таких сомнительных утверждений:

1. Методы второго и более порядков плохо работают в задачах обучения нейросетей. Потомучто.
2. Метод Ньютона требует положительной определенности матрицы Гессе (вторых производных) и поэтому плохо работает.
   
3. Метод Левенберга-Марквардта — компромисс между градиентным спуском и методом Ньютона и вообще эвристичекий.
   

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

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


Давайте разбираться

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

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

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

Сразу оговорюсь, на Хабре я новичок и как что работает имею очень смутное понятие. Однако взглянув на исходник страницы со статьей, в которой представлен фрагмент кода, стал понятен источник проблемы. И он *барабанная дробь* в том, что раскраской кода занимается JavaScript. Нет, для чтения через браузер это конечно хорошо и круто, но питоновская pisa, которая и занимается отрисовкой страницы в PDF, код раскраски выполнить не может в принципе.

Возникла идея — надо что-то придумать.