Thefittest: зачем я пишу свою open-source библиотеку эволюционных алгоритмов

[Asker1987]

Люто плюсую

[jee1ary]

Крутая работа! Всё хорошо объяснено. А вы не смотрели в сторону surrogate-assisted эволюционных алгоритмов? Они отлично себя показывают в expensive black-box оптимизации — особенно когда оценка кандидата стоит дорого. Кажется, это могло бы хорошо дополнить ваш подход для ресурсоёмких задач AutoML.

[Sherstpasha]

Спасибо! Да, такой подход сейчас действительно очень перспективен сегодня как раз смотрю в эту сторону и пока изучаю.

[Mi_Lis]

Статья полезная, однозначно плюс, но..
В чем проблема использовать DEAP для эволюционных алгоритмов?

[Sherstpasha]

Спасибо :) Если коротко, использовать DEAP для простого применения ЭА это как забивать гвозди микроскопом. Отличный инструмент для прототипирования идей и кастомизации алгоритмов, но не лучший вариант, если хочется применить готовый алгоритм «под ключ». И медленнее к тому же, а масштабируется намного хуже. Подробнее можно посмотреть в статье, если будет интересно https://elibrary.ru/item.asp?id=66233348

[rybakolbasa]

А на каких условиях предполагается коммерческое использование?

[pomponchik]

13 000 строк Python, из которых большая часть — основной функционал, а четверть — тесты

Это ужасное соотношение, библиотеку вряд ли можно назвать протестированной. Обычно хорошее соотношение кода к тестам начинается где-то от 1 к 5, т.е. в данном случае нужно примерно в 20 раз больше тестов.

[Sherstpasha]

Спасибо за комментарий! Пожалуй, Вы правы: я ориентировался в первую очередь на покрытие тестами (сейчас оно отображается как 86 %, хотя на деле ближе к 100 %, так как функции, скомпилированные через Numba, в отчете не учитываются), а не на соотношение кода и тестов. Статистику по строкам я посчитал уже постфактум при подготовке статьи. Я прислушаюсь к Вашему замечанию и при необходимости расширю тестирование. Отмечу также, что все estimators дополнительно прогоняются через тесты scikit-learn, что в итоге значительно увеличивает общее количество тестов.

[pomponchik]

По Numba-коду тоже можно считать покрытие.

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

Метрики типа покрытия (кстати, настоятельно рекомендую помимо обычного покрытия считать также покрытие "по бранчам", т.е. с автоматической проверкой, что обе ветки любого условия были протестированы) хороши только в качестве нижней планки. Лично у меня для библиотек включен трэшхолд в 100% покрытия по строкам и бранчам, на 99% и ниже просто CI не пройдет. Но это именно нижняя планка, 100% легко достичь, ничего на самом деле не протестировав, поэтому приходится иметь дополнительные интуиции, указывающие на возможные проблемы.

Из более интересных метрик могу посоветовать попробовать мутационное тестирование, возможно вам зайдет, раз вы интересуетесь эволюционными алгоритмами :) Возможно, получится разово словить какие-то инсайты от запуска mutmut, хотя готового прям к повседневному исследованию тулинга в этой области для Python пока нет (но я прямо сейчас работаю над этим). В целом это полезная штука, когда покрытие уже 100%, и все очевидные идеи, что можно протестировать, уже исчерпаны.

Удачи с проектом!