Материал из Linuxformat.

MathGL: Данные тоже нуждаются в представлении

Данные могут быть прекрасны не только с точки зрения исследователя. Для этого их следует хорошенько подготовить, и MathGL поможет здесь даже самому взыскательному эстету. Этот довольно очевидный факт теперь признали и во Франции. Евгений Балдин беседует c Алексеем Балакиным, победителем Les Trophe´es du Libre 2009.

Первая идея о том, что следует написать нечто вроде MathGL, посетила меня в районе 2003 года, когда мне впервые пришлось столкнуться с крупными (трехмерными) массивами данных и я осознал все проблемы, связанные с их визуализацией. На тот момент единственным пригодным инструментом являлся MATLAB… но и у него была, да и до сих пор остается куча недостатков: нестабильная работа с большими массивами, высокие накладные расходы при рисовании графиков (памяти надо много больше, чем занимает исходный массив) и, естественно, высокая цена (хотя тогда для меня это было не критично, так как все ПО было закуплено работодателем).

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

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

После того как предметные требования к программе были сформулированы, настало «дело техники». В 2005–2006 годах была написана первая версия для личного использования. Кстати, именно она применялась при подготовке важнейшего результата РАН в 2006 году («Исследование структурных особенностей динамики самофокусировки сверхкоротких импульсов с шириной спектра порядка центральной частоты»). В 2007 MathGL слегка расширилась и стала публичной. С тех пор идет постоянное улучшение (добавление новых типов графиков, возможностей, и т. д., и т. п.), основанное преимущественно на предложениях пользователей. На данный момент в MathGL только базовых типов графиков насчитывается более 50 штук (!).

Из того, чем стала сейчас MathGL, довольно весомая часть принадлежит и сообществу. Оно не только выдает предложения о новых возможностях и докладывает об имеющихся ошибках, но и вносит непосредственный вклад в сам открытый код. Например, Михаил Видасов добавил возможность для экспорта графики в формат U3D (Universal 3D). При включении U3D-графика в PDF, Adobe Reader (начиная с версии 8.1) позволяет мышью вращать, приближать и менять прочие его параметры прямо в файле, что увеличивает интерактивность электронных документов и презентаций.

MathGL изначально задумывалась как кросс-платформенная библиотека, так как мне надо было строить графики непосредственно на сервере/кластере, которые все (по крайней мере, за границей) работают под управлением Linux [и не за границей тоже, – прим. ред.]. В то же время схожий функционал был мне необходим и под Windows на локальной машине/ноутбуке.

С Unix-подобными системами я познакомился на первых курсах университета (1992 год), потом были расчеты на кластерах под Linux. В качестве настольной системы я попробовал его в 2003 году, когда начал задумываться о MathGL. Однако окончательный переход под Linux у меня произошел довольно поздно (два года назад) и поспособствовала этому, как ни странно, Microsoft. На очередном ноутбуке стояла Vista, которая была настолько «глючной» (особенно при разработке программ) и прожорливой по ресурсам, что, помучившись с ней месяц, я ее снес и поставил Debian (хотя на тот момент полная поддержка всего оборудования отсутствовала). С тех пор не испытываю никаких проблем с безопасностью, стабильностью и прочим, и только «посмеиваюсь» различным вирусным атакам и мучениям с созданием программ для Windows. Кстати, сдать Vista назад мне так и не удалось – правда, я не сильно и старался.

Путь к славе

Про Les Trophe´es du Libre узнал из новости на LOR (http://www.linux.org.ru). Подумал, почему бы не попробовать… C визой проблем не было, так как пару раз в год бываю за границей, и билеты они оплачивают, да и язык прилично знаю. Единственная сложность – это подгадать рабочую поездку и поездку на конкурс.

Финал конкурса проходил в Суассоне [Soissons] – маленьком, но довольно приятном городке в 90 километрах к северо-западу от Парижа. Франция мне понравилась, так как это первая европейская страна (не считая чисто туристических Праги и прочих), на архитектуру которой можно посмотреть с удовольствием. И первая, в которой есть нормальные леса (а не лесопарки; по крайней мере, мне так показалось). К сожалению, график был слишком плотный, и побродить мне не удалось… может быть, в следующий раз, благо победителей приглашают в жюри [улыбается].

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

Сам конкурс в целом прошел хорошо, хотя были и досадные накладки: все-таки не хватает опыта организации крупных мероприятий. Были довольно интересные проекты. Из того, что особенно понравилось – это игра Neverball (http://neverball.org). Интересно и необычно, рекомендую. Честно говоря, совершенно не понимаю, почему ей не дали первое место [она заняла второе, – прим. ред.] в категории Hobbies.

В моей категории (Sciences) у MathGL почти не было конкурентов. Один проект относился скорее к мультимедиа, а второй был слишком узкоспециализированным (да и мне кажется, что сходные инструменты есть почти в каждом университете – правда, как правило, закрытые).

Судейство было вполне приличным, хотя многое, естественно, зависело от предварительного впечатления и от презентации (это важно!). Предвзятый человек вполне может увидеть некоторое «перетягивание одеяла» на французские проекты, так как им позволяли говорить чуть подольше, да и рассказывали иногда по-французски. Но если проект качественный и есть опыт докладов, как, например, у меня [улыбается], то выиграть можно.

Отдельно хотелось бы отметить, что на конкурсе было, помимо моего, еще четыре проекта, выполненных русскоязычными авторами: UniConvertor Игоря Новикова (LXF100/101), Inquisitor Михаила Якшина (LXF119) и GSQL Тараса Халтурина. Очень хорошие проекты, за которые не стыдно. Дерзайте!

Советы номинантам

Если у вас есть желание поучаствовать и выиграть в конкурсе в будущем, то прежде всего следует тщательно подготовить презентацию. А лучше иметь их две-три: одну – краткую и яркую – для публики, и одну большую – для интересующихся. В «большой» презентации можно представить и историю, и структуру программы, и математическую модель, и прочее. А вот в краткой должны быть только картинки и результаты (плюс слайд, поясняющий, зачем это нужно). Учтите, что в реальности времени будет мало (оно тратится на переключение с компьютера на компьютер, на то, чтобы собраться с мыслями, и прочее), и жюри не очень-то интересно слушать проекты не по профилю. Ваша задача – «зацепить» человека, и лучше это сделать первыми слайдами. А уж все детали – потом, так как время для вопросов – это уже время сверх вашего доклада. Еще одно замечание: не надейтесь показать работу программы жюри, так как времени не будет, да и не оценят. Лучше делать презентацию (можно с анимацией) и хорошо ее проговорить.

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

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

Ну и, конечно, главный рецепт победы – это делать хорошие проекты. Больше свободных проектов, хороших и разных! LXF