Package, for «magic» visualization of datastructures of compact algorithms written on Python (like leetcode-codechef-spojcode tasks) during debugging on vscode/pydev.

Pyalgovizualizer

Проблемы

По личному опыту — 25 лет преподавания (МФТИ, ИСПРАН), и 35 лет учеником (ВУЗЫ, курсы, MOOCи), преподавание алгоритмов, как у нас, так и по миру, не то, чтобы «полный отстой», но сильно не дотягивает до возможного сейчас технологического уровня.

Да, когда-то, в ветхозаветные времена — времен поклонению библиям алгоритмов — трехтомнику Кнута, «книжке с ослом» («Алгоритмы: построение и анализ»), которых правда обычно держали на полках, а реально читали плохонапечатанные методички ВУЗов, и только те, казалось — что все правильно и так и должно быть — хотя работало это только для тех, кто реально пытался все это как-то кодить.

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

Но надо признать очевидные «для 2024» факты: «бумажные книги — все».

По форме:

• нельзя искать,
• неудобно (для 2024) читать,
• невозможно копировать и как-то взаимодействовать.
• кирпич! не унести, не скопировать, не …
• качественная печать — белая бумага, цветные иллюстрации — адски дорого, обычно на бумаге «стандарт Питер-пресс» с серой «туалетной бумагой».

Любители «запаха бумажных листов», «шелеста страниц», «разрезания упаковки» — мною не наблюдались уже давно.

Также по процессу издания:

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

Давайте не тратить кучу сил на верстку, впихивание слабовпихуемого в прокрутово ложе «листа бумаги», «чернобелой печати», когда это просто ненужно — читать будут с разных устройств, телефонов, планшетов, портретно и альбомно ориентированных мониторов разного разрешения, где нужна адаптивная верстка, нет ограничений на объем, но есть цвета и гиперссылки и возможность интерактивности, которые пропадают в книгах. Не нужны ни бумажные учебники, ни специализированные гибкие-негибкие e-ink устройства — это я говорю, как владелец нескольких десятков «электронных книг».

Так что проехали! Не говоря уж о том, что в РФ полезно бы вообще держатся подальше от издательского бизнеса учебников — там до сих пор мафия, перестрелки, бандиты с золотыми цепями (опыт хороших знакомых, общавшегося с).

Казалось бы — электронные PDF-книги, прекрасно написанные, адаптированные для чтения с планшетов, с правильными экранными шрифтами, мониторной версткой, с цветными картинками и гиперссылками, читаем на компьютерах и планшетах, публикуем-обновляем на сайте сами, используем цвет-поиск… — проблема решена?

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

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

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

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

Сначала пройдемся по явно неудачным концептам, чтобы их избегать:

• «Алгоритм словами» — полный отстой. Может создать иллюзию понимания, но скорее всего ложную.
• «Псевдокод» — иллюзия понимания, но есть проблема воспроизводимости — при переходе к работающему алгоритму, может выяснится, даже при правильной реализации, что алгоритм вовсе не работал. Дилемма «Точность против Понятности» конечно очевидна, но псевдокод, каким бы понятным он был, за пределами правильного решения.
• Проблемы подачи контента — как говорилось выше, статика типа книг-статей-слайдов не передают динамики алгоритма — что-то можно делать с автогенерацией слайдов или картинок, но это очень мучительно и ограничено.

Это решения с более интересны, но тоже имеют свои недостатки:

• Процедурная видеоанимация (пакет manim) — красиво, но непонятно, что выполняется, сложно исследовать, нет синхронизации между роликами и выполняемым кодом.
• «Literate programming» — что-то подобное я делал ранее в книге и слайдах — генерация из питон кода, компактного описания алгорима картинок и слайдов, но явно вижу пределы, и это сильно мучительно.
• Jupyter-ноутбуки. Хороши для представления однонаправленных процессов (пайплайнов ML), постановок ЦЛП/SAT-задач, но не для самих алгоритмов, где происходят нетривиальные манипуляции — хотя в принципе, что-то достаточно неплохо можно показывать с поддержкой отладки в VSCode.

В идеале видится именно живой алгоритм, с которым можно играться, изучать=эспериментировать, анализировать каждый шаг, но при этом чтобы было понятно и быстро. «Talks is cheap, show me the code» — казалось бы надо просто написать очень понятный код, в видеоролике разбирать его работу, и дать возможность легко обучающемуся повторить все это, поэкспериментировать с каждой строчкой, покачать разные «что-если». Так в общем, уже и делает «весь интернетный мир», при эффективном изучении всего связанного с IT и это хорошо.

Но есть проблемы такого подхода, по отношению к преподаванию сложных алгоритмов:

• Алгоритмы на индустриальных языках (С/C++/Java/Rust…) — чудовищная перегрузка ненужными подробностями.
• проблема с визуализацией изменения состояния — просто тыкать в отладочные описания структур — неэффективно.
  • Чуть помогает расширение VSCode «Debug Visualizer» — но там долго перерисовывается, очень нетривиально (JSON-программирование) описывать визуализацию.

---

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

Решение — разработанный питон-модуль pyalgovisualizer, использующий

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

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

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

Ну или заходите на алгоритм.эвристика.рф, сейчас там пароль ArthurFomin1729, открывайте readme.md и попробуйте поотлаживать любой из алгоритмов, открыв в отдельной панели редактора картинку .visualization.png, и просматривая объясняющие ролики в начале описания каждого алгоритма.