Подробный план развития SciPy#

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

Примечание

Это подробный план. Очень высокоуровневый обзор только с самыми важными идеями Дорожная карта SciPy.

Общее#

Эта дорожная карта будет развиваться вместе с SciPy. Обновления могут быть представлены как запросы на включение изменений. Для крупных или кардинальных изменений вы можете сначала обсудить их на форуме scipy-dev.

Изменения API#

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

Покрытие тестами#

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

Помимо покрытия, есть также вопрос корректности — старый код может иметь несколько тестов, которые обеспечивают достойное покрытие операторов, но это не обязательно говорит о том, делает ли код то, что заявлено. Поэтому рецензирование кода некоторых частей кода (stats, signal и ndimage в частности) необходимо.

Документация#

Документация находится в хорошем состоянии. Следует продолжать расширение текущих docstrings — добавление примеров, ссылок и лучших объяснений. Большинство модулей также имеют учебник в справочном руководстве, который является хорошим введением, однако есть несколько отсутствующих или неполных учебников — это следует исправить.

Бенчмарки#

The asv-ориентированная система бенчмарков находится в разумном состоянии. Добавлять новые бенчмарки довольно легко, однако запуск бенчмарков не очень интуитивен. Упрощение этого процесса является приоритетом.

Использование Cython#

Старый синтаксис Cython для использования массивов NumPy должен быть удалён и заменён на представления памяти Cython.

Бинарные размеры расширений, собранных из кода Cython, велики, а время компиляции длительное. Мы должны стремиться объединять модули расширений, где это возможно (например, stats._boost содержит множество модулей расширения), и ограничить использование Cython местами, где это лучший выбор. Обратите внимание, что преобразование Cython в C++ продолжается в scipy.special.

Использование Pythran#

Pythran по-прежнему является опциональной зависимостью сборки и может быть отключен с помощью -Duse-pythran=falseЦель состоит в том, чтобы сделать его обязательной зависимостью - для этого необходимо убедиться, что нагрузка на поддержку достаточно низкая.

Использование библиотек Fortran#

SciPy во многом обязан своим успехом использованию хорошо зарекомендовавших себя библиотек на Fortran (QUADPACK, FITPACK, ODRPACK, ODEPACK и др.). Fortran 77, на котором написаны эти библиотеки, довольно сложно поддерживать, и использование Fortran проблематично по многим причинам; например, это значительно усложняет поддержку сборки наших wheel, неоднократно вызывало проблемы при поддержке новых платформ, таких как macOS arm64 и Windows на Arm, и крайне проблематично для поддержки SciPy в Pyodide. Наша цель — удалить весь код на Fortran из SciPy, заменив функциональность кодом, написанным на других языках. Прогресс в достижении этой цели отслеживается в gh-18566.

Непрерывная интеграция#

Непрерывная интеграция в настоящее время охватывает 32/64-битные Windows, macOS на x86-64/arm, 32/64-битный Linux на x86 и Linux на aarch64 — а также ряд версий наших зависимостей и сборку релизных колес. Надёжность CI не была хорошей в последнее время (первая половина 2023 года) из-за большого количества поддерживаемых конфигураций и необходимости переработки некоторых задач CI. Мы стремимся сократить время сборки, удалив оставшиеся задачи на основе distutils, когда мы откажемся от этой системы сборки, и сделав набор конфигураций в задачах CI более ортогональным.

Размер бинарных файлов#

Бинарные файлы SciPy довольно большие (например, неупакованный manylinux wheel для 1.7.3 занимает 39 МБ на PyPI и 122 МБ после установки), и это может быть проблематично — например, для использования в AWS Lambda, где ограничение размера составляет 250 МБ. Мы стремимся сохранять размер бинарных файлов как можно меньше; при добавлении новых скомпилированных расширений это требует проверки. Удаление отладочных символов в multibuild возможно, может быть улучшена (см. этой проблемы). Следует приложить усилия для сокращения размера там, где это возможно, и не добавлять новые большие файлы. В будущем рассматриваются (очень предварительно) варианты, которые могут помочь, такие как отделение встроенных libopenblas и удаление поддержки для long double.

Модули#

cluster#

dendrogram требует переработки, у него есть ряд трудноисправимых открытых проблем и запросов на функции.

constants#

Этот модуль требует только периодических обновлений числовых значений.

differentiate#

Этот модуль был добавлен с пониманием, что его область применения будет ограничена. Цель — обеспечить базовое дифференцирование функций типа "чёрный ящик", а не воспроизводить все возможности существующих инструментов дифференцирования. С учётом этого, задачи на будущее включают:

  • Улучшена поддержка вызываемых объектов, принимающих дополнительные аргументы (например, добавлена аналогичная фабричная функция для сплайн-аппроксимации) *args to jacobian и hessian). Обратите внимание, что это нетривиально из-за способа исключения элементов массивов, когда соответствующие вычисления сошлись.

  • Улучшить реализацию scipy.differentiate.hessian: вместо цепочки дифференцирования первого порядка использовать шаблон дифференцирования второго порядка.

  • Рассмотрим добавление опции использования относительных размеров шага.

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

fft#

Этот модуль в хорошем состоянии.

интегрировать#

  • Завершение набора функций нового cubature функцию и добавить интерфейс, адаптированный для одномерных интегралов.

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

  • Завершить набор функций solve_ivp, включая всю функциональность odeint интерфейс.

  • Плавно выводить из использования устаревшие функции и классы.

интерполировать#

Замены FITPACK

Нам необходимо завершить предоставление функциональных эквивалентов библиотеки FITPACK на Fortran. Цель — перереализовать алгоритмическое содержимое монолита FITPACK в модульном виде, чтобы обеспечить лучший контроль и расширяемость для пользователей. Для этого нам нужно

  • 1D сплайны: добавить периодическую аппроксимацию сплайнами в make_splrep функция.

  • 2D сплайны: предоставить функциональные замены для BivariateSpline семейство классов для разбросанных и сеточных данных.

Как только у нас будет полный набор замен функций, мы сможем плавно прекратить использование FITPACK.

Идеи для новых функций

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

  • #8056 make_smoothing_spline и скачки 3-й производной от make_splrep

  • исследовать способы векторизации построения сплайнов для батчей независимой переменной. Этот класс функций был запрошен scipy.stats разработчики

  • позволяет задавать граничные условия для аппроксимации сплайнами.

  • исследовать задачи аппроксимации сплайнами с ограничениями, которые библиотека FITPACK предоставляла на Fortran, но никогда не экспонировала в интерфейсы Python

  • Поддержка NURBS может быть добавлена при достаточном интересе пользователей

Масштабируемость и производительность

Нам необходимо проверить производительность на больших наборах данных и улучшить её там, где это требуется. Это актуально как для интерполяторов на регулярной сетке N-D, так и для интерполяторов на разбросанных данных N-D на основе QHull. Для последних нам дополнительно необходимо исследовать, можем ли мы улучшить ограничения библиотеки QHull на 32-битные целые числа.

io#

wavfile:

  • PCM float будет поддерживаться, для всего остального используйте audiolab или другие специализированные библиотеки.

  • Выдавать ошибки вместо предупреждений, если данные не распознаны.

Другие подмодули (matlab, netcdf, idl, harwell-boeing, arff, matrix market) находятся в хорошем состоянии.

linalg#

scipy.linalg в хорошем состоянии.

Требуется:

  • Сокращение дублирования функций с помощью numpy.linalg, сделать API согласованными.

  • get_lapack_funcs всегда следует использовать flapack

  • Обернуть больше функций LAPACK

  • Слишком много функций для LU-разложения, удалить одну

Идеи для новых функций:

  • Добавить обобщённые по типам обёртки в Cython BLAS и LAPACK

  • Преобразовать многие подпрограммы линейной алгебры в gufuncs

  • Полная поддержка пакетных операций (см. gh-21466)

BLAS и LAPACK

Интерфейсы Python и Cython к BLAS и LAPACK в scipy.linalg являются одним из наиболее важных элементов, предоставляемых SciPy. В общем случае scipy.linalg находится в хорошем состоянии, однако мы можем внести ряд улучшений:

  1. Добавление поддержки ILP64 (64-битных) BLAS и LAPACK (см. gh-21889)

  2. Унифицировать два набора низкоуровневых обёрток BLAS/LAPACK, вероятно, удалив f2py-based ones (см. gh-20682)

  3. Улучшить и задокументировать различные способы подключения к BLAS и LAPACK из кода на C и C++ внутри SciPy (см. gh-20002 и gh-21130)

misc#

Все функции были удалены из scipy.misc, и само пространство имён в конечном итоге будет удалено.

ndimage#

Базовый ndimage является мощным интерполяционным механизмом. Пользователи приходят с ожиданием одной из двух моделей: пиксельной модели с (1, 1) элементы, имеющие центры (0.5, 0.5), или модель точек данных, где значения определены в точках на сетке. Со временем мы убедились, что модель точек данных лучше определена и проще в реализации, но это должно быть четко указано в документации.

Что еще более важно, SciPy реализует один вариант этой модели точек данных, где точки данных на любых двух крайних точках оси имеют общее пространственное расположение при периодическое обёртывание режим. Например, в одномерном массиве, вы бы имели x[0] и x[-1] совмещены. Очень распространённый случай использования, однако, когда сигналы периодические, с равным расстоянием между первым и последним элементом вдоль оси (вместо нулевого расстояния). Режимы обёртки для этого случая были добавлены в gh-8537, затем процедуры интерполяции должны быть обновлены для использования этих режимов. Это должно решить несколько проблем, включая gh-1323, gh-1903, gh-2045 и gh-2640.

Интерфейс морфологии необходимо стандартизировать:

  • бинарное расширение/эрозия/открытие/закрытие принимают аргумент "structure", тогда как их серые эквиваленты принимают size (должен быть кортежем, не скаляром), footprint или structure.

  • скаляр должен быть допустимым для size, что эквивалентно предоставлению того же значения для каждой оси.

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

  • другие фильтры также должны принимать это значение по умолчанию, где это возможно.

odr#

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

оптимизировать#

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

  • Улучшить интерфейсы существующих оптимизаторов (например, shgo).

  • Улучшение удобства использования системы бенчмарков и добавление функций для более лёгкого сравнения результатов (например, сводные графики).

сигнал#

Свёртка и корреляция: (Соответствующие функции: convolve, correlate, fftconvolve, convolve2d, correlate2d и sepfir2d.) Устранить перекрытие с ndimage (и в других местах). Из numpy, scipy.signal и scipy.ndimage (и везде, где мы их находим), выбрать «лучший в классе» для 1-D, 2-D и n-d свертки и корреляции, разместить реализацию где-то и использовать её последовательно во всём SciPy.

B-сплайны: (Соответствующие функции: gauss_spline, cspline1d, qspline1d, cspline2d, qspline2d, cspline1d_eval и spline_filter.) Перенести полезные материалы в интерполировать (с соответствующими изменениями API, чтобы соответствовать тому, как это делается в интерполировать), и устранить любое дублирование.

Проектирование фильтров: слияние firwin и firwin2 так firwin2 может быть удалена.

Линейные системы непрерывного времени: Дальнейшее улучшение производительности ltisys (меньше внутренних преобразований между разными представлениями). Заполнить пробелы в функциях преобразования систем lti.

Секции второго порядка: Сделать фильтрацию SOS такой же мощной, как существующие методы. Это включает объекты ltisys, а lfiltic эквивалентные и численно устойчивые преобразования в другие представления фильтров и из них. Фильтры SOS можно рассматривать как метод фильтрации по умолчанию для объектов ltisys из-за их численной устойчивости.

разреженный#

Форматы разреженных матриц в основном завершены по функционалу, однако основная проблема в том, что они ведут себя как numpy.matrix (который будет устаревшим в NumPy в какой-то момент).

Нам нужны разреженные массивы, которые ведут себя как numpy.ndarray. Начальная поддержка нового набора классов (csr_array и др.) был добавлен в SciPy 1.8.0 и стабилизирован в 1.12.0 с функциями создания массивов, 1.14.0 с поддержкой 1D массивов и 1.15.0 с 1D индексацией. Кодовая база разреженных массивов теперь поддерживает все функции разреженных матриц и, кроме того, поддерживает 1D массивы и первые шаги к nD массивам. Существует руководство по переходу, чтобы помочь пользователям и библиотекам преобразовать свой код в разреженные массивы.

Следующие шаги к преобразованию в разреженный массив:

  • Расширить API разреженных массивов до nD массивов.

    • Поддержка форматов COO, CSR и DOK.

    • Некоторые функции COO существуют в версии 1.15.

  • Добавить поддержку broadcasting в операциях, где разреженные форматы могут эффективно это делать.

  • Помогите другим библиотекам перейти от разреженных матриц к разреженным массивам. NetworkX, dipy, scikit-image, pyamg, cvxpy и scikit-learn находятся в процессе или завершили переход на разреженные массивы.

  • Добавить предупреждения об устаревании для разреженной матрицы.

  • Работа с NumPy по устареванию/удалению numpy.matrix.

  • Устаревание и последующее удаление разреженной матрицы в пользу разреженного массива.

  • Начало API-сдвига имён функций построения (diags, block, и т.д.)

    • Примечание: в целом функции построения претерпевают два сдвига в именах. Один для перехода от создания матриц к новым функциям создания массивов (т.е. eye -> eye_array). Затем второе изменение для переименования в соответствии с array_api имя (т.е. eye_array to eye) после удаления разреженных матриц. Мы сохраним *_array версии в течение долгого времени как (возможно скрытые) псевдонимы.

  • Добавить имена функций построения, соответствующие array_api имена.

  • Устаревание названий функций построения переходов.

Альтернативный (более амбициозный и неясно, будет ли реализован) план разрабатывается в pydata/sparse. Для поддержки этой работы мы стремимся поддерживать PyData Sparse во всех функциях, которые принимают разреженные массивы. Поддержка для pydata/sparse в scipy.sparse.linalg и scipy.sparse.csgraph в основном завершена.

Относительно различных форматов разреженных матриц: их много. Их следует сохранить, но улучшения/оптимизации должны внедряться в CSR/CSC, которые являются предпочтительными форматами. LIL может быть исключением, он по своей природе неэффективен. Его можно удалить, если DOK расширить для поддержки всех операций, которые в настоящее время предоставляет LIL.

sparse.csgraph#

Этот модуль в хорошем состоянии.

sparse.linalg#

Существует значительное количество открытых проблем для _arpack и lobpcg.

_isolve:

  • ключевое слово callback непоследовательно

  • ключевое слово tol сломано, должно быть относительное tol

  • Код Fortran не реентерабельный (но мы не решаем, возможно, повторное использование из PyKrilov)

_dsolve:

  • добавить разреженное или неполное разложение Холецкого, совместимое с лицензией

  • добавить разреженный QR с совместимой лицензией

  • улучшить интерфейс к SuiteSparse UMFPACK

  • добавить интерфейсы к SuiteSparse CHOLMOD и SPQR

пространственный#

Обёртки QHull находятся в хорошем состоянии, как и KDTree.

Переписывание spatial.distance Реализация метрик на C++ находится в процессе разработки - это должно улучшить производительность, сделать поведение (например, для различных входных типов данных, отличных от float64) более согласованным и исправить несколько оставшихся проблем с определениями математической реализации для некоторых метрик.

специальный#

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

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

  2. Портировать библиотеку произвольной точности Boost и использовать её в качестве основы для получения точности двойной точности. Это может быть необходимо как временная мера для гипергеометрических функций; идея использования произвольной точности была предложена ранее @nmayorov и в gh-5349. Вероятно, необходимо для сфероидальных волновых функций, это можно повторно использовать: radelman/scattering.

  3. Добавить чёткие предупреждения в документацию об ограничениях существующих реализаций.

stats#

The scipy.stats подпакет стремится предоставить фундаментальные статистические методы, которые могут быть рассмотрены в стандартных учебниках по статистике, таких как "Miller & Freund's Probability and Statistics for Engineers" Джонсона, "Biometry" Сокала и Рольфа или "Biostatistical Analysis" Зара. Он не стремится дублировать расширенную функциональность последующих пакетов (например, StatsModels, LinearModels, PyMC3); вместо этого он может предоставить прочную основу, на которой они могут строить. (Обратите внимание, что это приблизительные рекомендации, а не строгие правила. "Расширенный" — это плохо определённый и субъективный термин, и "расширенные" методы также могут быть включены в SciPy, особенно если никакой другой широко используемый и хорошо поддерживаемый пакет не охватывает тему. Также обратите внимание, что некоторые дублирование с нижестоящими проектами неизбежно и не обязательно является плохим.)

Следующие улучшения помогут SciPy лучше выполнять эту роль.

  • Улучшить статистические тесты: включить методы генерации доверительных интервалов и реализовать точные и рандомизированные вычисления p-значений - с учётом возможности совпадений - где это вычислительно осуществимо.

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

  • Улучшить инфраструктуру многомерных распределений для обеспечения согласованного API, тщательного тестирования и полной документации.

  • Продолжайте делать API функций более согласованными, со стандартной поддержкой пакетных вычислений, политик NaN и сохранения типов данных.