Примечания к выпуску NumPy 1.20.0#

Этот выпуск NumPy является крупнейшим на сегодняшний день, объединено около 684 PR, внесённых 184 людьми. Подробности смотрите в списке основных изменений ниже. Поддерживаемые версии Python для этого выпуска — 3.7-3.9, поддержка Python 3.6 прекращена. Основные изменения:

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

  • Более широкое использование SIMD для увеличения скорости выполнения универсальных функций. Много работы было проделано по внедрению универсальных функций, которые упростят использование современных возможностей на различных аппаратных платформах. Эта работа продолжается.

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

  • Значительные улучшения документации, включающие около 185 слияний PR. Эта работа продолжается и является частью более крупного проекта по улучшению онлайн-присутствия NumPy и полезности для новых пользователей.

  • Дополнительная очистка, связанная с удалением Python 2.7. Это улучшает читаемость кода и устраняет технический долг.

  • Предварительная поддержка предстоящего Cython 3.0.

Новые функции#

Класс random.Generator имеет новый permuted функция.#

Новая функция отличается от shuffle и permutation в том смысле, что подмассивы, индексируемые осью, переставляются, а не ось рассматривается как отдельный 1-D массив для каждой комбинации других индексов. Например, теперь можно переставлять строки или столбцы 2-D массива.

(gh-15121)

sliding_window_view предоставляет скользящее оконное представление для массивов numpy#

numpy.lib.stride_tricks.sliding_window_view создает представления массивов numpy, которые предоставляют скользящий или движущийся доступ к массиву. Это позволяет просто реализовать определенные алгоритмы, такие как скользящие средние.

(gh-17394)

numpy.broadcast_shapes это новая пользовательская функция#

broadcast_shapes получает результирующую форму из вещания заданных кортежей форм друг с другом.

>>> np.broadcast_shapes((1, 2), (3, 1))
(3, 2)

>>> np.broadcast_shapes(2, (3, 1))
(3, 2)

>>> np.broadcast_shapes((6, 7), (5, 6, 1), (7,), (5, 1, 7))
(5, 6, 7)

(gh-17535)

Устаревшие функции#

Использование псевдонимов встроенных типов, таких как np.int устарел#

В течение долгого времени, np.int был псевдонимом встроенного int. Это часто вызывает путаницу у новичков и существовало в основном по историческим причинам.

Эти псевдонимы устарели. В таблице ниже показан полный список устаревших псевдонимов вместе с их точным значением. Замена элементов в первом столбце содержимым второго столбца будет работать идентично и отключит предупреждение об устаревании.

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

Устаревшее имя

Идентично

имена скалярных типов NumPy

numpy.bool

bool

numpy.bool_

numpy.int

int

numpy.int_ (по умолчанию), numpy.int64, или numpy.int32

numpy.float

float

numpy.float64, numpy.float_, numpy.double (эквивалентно)

numpy.complex

complex

numpy.complex128, numpy.complex_, numpy.cdouble (эквивалентно)

numpy.object

object

numpy.object_

numpy.str

str

numpy.str_

numpy.long

int

numpy.int_ (C long), numpy.longlong (наибольший целочисленный тип)

numpy.unicode

str

numpy.unicode_

Чтобы дать чёткое руководство для подавляющего большинства случаев, для типов bool, object, str (и unicode) использование простой версии короче и понятнее и обычно является хорошей заменой. Для float и complex вы можете использовать float64 и complex128 если вы хотите быть более явным о точности.

Для np.int прямая замена на np.int_ или int также хорошо и не изменит поведение, но точность продолжит зависеть от компьютера и операционной системы. Если вы хотите быть более явным и просмотреть текущее использование, у вас есть следующие альтернативы:

  • np.int64 или np.int32 чтобы точно указать точность. Это гарантирует, что результаты не зависят от компьютера или операционной системы.

  • np.int_ или int (по умолчанию), но имейте в виду, что это зависит от компьютера и операционной системы.

  • Типы C: np.cint (int), np.int_ (long), np.longlong.

  • np.intp который является 32-битным на 32-битных машинах и 64-битным на 64-битных машинах. Это может быть лучшим типом для использования в индексации.

При использовании с np.dtype(...) или dtype=... изменение его на имя NumPy, как упомянуто выше, не повлияет на вывод. Если используется как скаляр с:

np.float(123)

изменение может незаметно изменить результат. В этом случае версия Python float(123) или int(12.) обычно предпочтительнее, хотя версия NumPy может быть полезна для согласованности с массивами NumPy (например, NumPy ведет себя иначе для таких вещей, как деление на ноль).

(gh-14882)

Передача shape=None для функций с необязательным аргументом shape устарело#

Ранее это было псевдонимом для передачи shape=(). Это устаревание выдается PyArray_IntpConverter в C API. Если ваш API предназначен для поддержки передачи None, тогда вы должны проверить на None перед вызовом конвертера, чтобы иметь возможность различать None и ().

(gh-15886)

Ошибки индексации будут сообщаться даже когда результат индексации пуст#

В будущем NumPy будет вызывать IndexError, когда целочисленный индекс массива содержит значения вне границ, даже если неиндексированное измерение имеет длину 0. Теперь это будет вызывать DeprecationWarning. Это может произойти, когда массив ранее пуст, или задействован пустой срез:

arr1 = np.zeros((5, 0))
arr1[[20]]
arr2 = np.zeros((5, 5))
arr2[[20], :0]

Ранее непустой индекс [20] не проверялась на корректность. Теперь она будет проверяться, вызывая предупреждение об устаревании, которое будет превращено в ошибку. Это также относится к присваиваниям.

(gh-15900)

Неточные совпадения для mode и searchside устарели#

Неточные и нечувствительные к регистру совпадения для mode и searchside были допустимыми входными данными ранее и теперь выдают предупреждение об устаревании. Например, ниже приведены некоторые примеры использования, которые теперь устарели и выдают предупреждение об устаревании:

import numpy as np
arr = np.array([[3, 6, 6], [4, 5, 1]])
# mode: inexact match
np.ravel_multi_index(arr, (7, 6), mode="clap")  # should be "clip"
# searchside: inexact match
np.searchsorted(arr[0], 4, side='random')  # should be "right"

(gh-16056)

Устаревание numpy.dual#

Модуль numpy.dual устарело. Вместо импорта функций из numpy.dual, функции должны импортироваться напрямую из NumPy или SciPy.

(gh-16156)

outer и ufunc.outer устарело для матрицы#

np.matrix использовать с outer или общие внешние вызовы ufunc такие как numpy.add.outer. Ранее матрица здесь преобразовывалась в массив. В будущем это не будет выполняться автоматически, потребуется ручное преобразование в массивы.

(gh-16232)

Дополнительные числовые стили типов устарели#

Оставшиеся числовые коды типов Bytes0, Str0, Uint32, Uint64, и Datetime64 были устаревшими. Следует использовать варианты в нижнем регистре вместо них. Для байтов и строк "S" и "U" являются дальнейшими альтернативами.

(gh-16554)

The ndincr метод ndindex устарел#

Документация предупреждала об использовании этой функции начиная с NumPy 1.8. Используйте next(it) вместо it.ndincr().

(gh-17233)

Объекты ArrayLike, которые не определяют __len__ и __getitem__#

Объекты, которые определяют один из протоколов __array__, __array_interface__, или __array_struct__ но не являются последовательностями (обычно определяются наличием __len__ и __getitem__Генерировать случайные числа uint64 в закрытом интервале [off, off + rng].

Когда вложены внутри последовательностей, таких как np.array([array_like]), эти обрабатывались как один объект Python, а не как массив. В будущем они будут вести себя идентично:

np.array([np.array(array_like)])

Это изменение должно иметь эффект только если np.array(array_like) не является 0-D. Решение этого предупреждения может зависеть от объекта:

  • Некоторые array-подобные объекты могут ожидать нового поведения, и пользователи могут игнорировать предупреждение. Объект может выбрать раскрытие протокола последовательности, чтобы включить новое поведение.

  • Например, shapely позволит преобразовать в массивоподобный объект с помощью line.coords вместо np.asarray(line). Пользователи могут обойти предупреждение или использовать новое соглашение, когда оно станет доступным.

К сожалению, использование нового поведения может быть достигнуто только вызовом np.array(array_like).

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

arr = np.empty(3, dtype=object)
arr[:] = [array_like1, array_like2, array_like3]

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

(gh-17973)

Будущие изменения#

Массивы не могут использовать подмассивные типы данных#

Создание массива и приведение типов с использованием np.array(arr, dtype) и arr.astype(dtype) будет использовать другую логику, когда dtype является подмассивным dtype, таким как np.dtype("(2)i,").

Для такого dtype следующее поведение верно:

res = np.array(arr, dtype)

res.dtype is not dtype
res.dtype is dtype.base
res.shape == arr.shape + dtype.shape

Но res заполняется с использованием логики:

res = np.empty(arr.shape + dtype.shape, dtype=dtype.base)
res[...] = arr

который использует некорректное вещание (и часто приводит к ошибке). В будущем это будет приводить к приведению каждого элемента по отдельности, что приведёт к тому же результату, что и:

res = np.array(arr, dtype=np.dtype(["f", dtype]))["f"]

Что обычно можно использовать для включения нового поведения.

Это изменение не затрагивает np.array(list, dtype="(2)i,") если только list сам включает хотя бы один массив. В частности, поведение не изменяется для списка кортежей.

(gh-17596)

Устаревшие устаревания#

  • Устаревание числовых стилей кодов типов np.dtype("Complex64") (с заглавными буквами), устарел. "Complex64" соответствовал "complex128" и "Complex32" соответствовал "complex64".

  • Устаревание np.sctypeNA и np.typeNA истёк. Оба были удалены из публичного API. Используйте np.typeDict вместо этого.

    (gh-16554)

  • 14-летнее устаревание np.ctypeslib.ctypes_load_library истёк. Используйте load_library вместо этого, что идентично.

    (gh-17116)

Финансовые функции удалены#

В соответствии с NEP 32, финансовые функции удалены из NumPy 1.20. Удалены следующие функции: fv, ipmt, irr, mirr, nper, npv, pmt, ppmt, pv, и rate. Эти функции доступны в numpy_financial библиотека.

(gh-17067)

Примечания по совместимости#

isinstance(dtype, np.dtype) и не type(dtype) is not np.dtype#

Типы данных NumPy не являются прямыми экземплярами np.dtype больше. Код, который мог использовать type(dtype) is np.dtype всегда возвращает False и должны быть обновлены для использования правильной версии isinstance(dtype, np.dtype).

Это изменение также затрагивает макрос на стороне C PyArray_DescrCheck если скомпилировано против NumPy старше 1.16.6. Если код использует этот макрос и хочет компилироваться против более старой версии NumPy, он должен заменить макрос (см. также Изменения в C API раздел).

Приведение того же типа в concatenate с axis=None#

Когда concatenate вызывается с axis=None, развернутые массивы были приведены с помощью unsafe. Любой другой выбор оси использует приведение "same kind". Это различие в поведении по умолчанию устарело, и вместо него будет использоваться приведение "same kind". Новый casting аргумент-ключевое слово может использоваться для сохранения старого поведения.

(gh-16134)

Скаляры NumPy приводятся при присваивании массивам#

При создании или присваивании массивов, во всех соответствующих случаях скаляры NumPy теперь будут приводиться идентично массивам NumPy. В частности, это изменяет поведение в некоторых случаях, которые ранее вызывали ошибку:

np.array([np.float64(np.nan)], dtype=np.int64)

будет успешным и вернет неопределенный результат (обычно наименьшее возможное целое число). Это также влияет на присваивания:

arr[0] = np.float64(np.nan)

На данный момент NumPy сохраняет поведение для:

np.array(np.float64(np.nan), dtype=np.int64)

Вышеуказанные изменения не затрагивают скалярные значения Python:

np.array([float("NaN")], dtype=np.int64)

остаётся неизменным (np.nan является Python float, а не NumPy). В отличие от знаковых целых чисел, беззнаковые целые не сохраняют этот особый случай, поскольку они всегда вели себя больше как приведение типа. Следующий код перестаёт вызывать ошибку:

np.array([np.float64(np.nan)], dtype=np.uint64)

Чтобы избежать проблем с обратной совместимостью, в настоящее время присваивание из datetime64 преобразование скаляра в строки слишком короткой длины остаётся поддерживаемым. Это означает, что np.asarray(np.datetime64("2020-10-10"), dtype="S5") теперь успешно, когда раньше терпело неудачу. В долгосрочной перспективе это может быть устаревшим или небезопасное приведение может быть разрешено в целом, чтобы сделать присваивание массивов и скаляров последовательным.

Изменения приведения массивов при смешивании строк и других типов#

Когда строки и другие типы смешиваются, например:

np.array(["string", np.float64(3.)], dtype="S")

Результаты изменятся, что может привести к строковым типам данных с более длинными строками в некоторых случаях. В частности, если dtype="S" если не предоставлено никакое числовое значение, это приведет к строковым результатам достаточной длины для хранения всех возможных числовых значений (например, "S32" для чисел с плавающей точкой). Обратите внимание, что вы всегда должны предоставлять dtype="S" при преобразовании не-строк в строки.

Если dtype="S" предоставлен, результаты будут в основном идентичны предыдущим, но скаляры NumPy (не Python float, как 1.0), всё равно будет обеспечивать единую длину строки:

np.array([np.float64(3.)], dtype="S")  # gives "S32"
np.array([3.0], dtype="S")  # gives "S3"

Ранее первая версия давала тот же результат, что и вторая.

Приведение массива к новой структуре#

Приведение массивов было переструктурировано. В целом это не должно затрагивать пользователей. В крайне редких угловых случаях, когда массиво-подобные объекты вложены:

np.array([array_like1])

Теперь всё будет более согласованно с:

np.array([np.array(array_like1)])

Это может незаметно изменить вывод для некоторых плохо определённых объектов, подобных массивам. Один пример таких объектов — те, которые не являются также последовательностями соответствующей формы. В NumPy 1.20 будет выдано предупреждение, когда объект, подобный массиву, не является также последовательностью (но поведение остаётся идентичным, см. устаревания). Если объект, подобный массиву, также является последовательностью (определяет __getitem__ и __len__) NumPy теперь будет использовать только результат, предоставленный __array__, __array_interface__, или __array_struct__. Это приведёт к различиям, когда (вложенная) последовательность описывает другую форму.

(gh-16200)

Запись в результат numpy.broadcast_arrays будет экспортировать буферы только для чтения#

В NumPy 1.17 numpy.broadcast_arrays начал выдавать предупреждение при записи в результирующий массив. Это предупреждение пропускалось, когда массив использовался через интерфейс буфера (например, memoryview(arr)). То же самое теперь будет происходить для двух протоколов __array_interface__, и __array_struct__ возвращая буферы только для чтения вместо выдачи предупреждения.

(gh-16350)

Имена типов в числовом стиле были удалены из словарей типов#

Чтобы оставаться в синхронизации с устареванием для np.dtype("Complex64") и другие числовые типы (в верхнем регистре). Они были удалены из np.sctypeDict и np.typeDict. Вместо этого следует использовать версии в нижнем регистре. Обратите внимание, что "Complex64" соответствует "complex128" и "Complex32" соответствует "complex64". Версии в стиле numpy (новые) обозначают полный размер, а не размер действительной/мнимой части.

(gh-16554)

The operator.concat функция теперь вызывает TypeError для аргументов-массивов#

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

(gh-16570)

nickname атрибут удалён из ABCPolyBase#

Абстрактное свойство nickname был удален из ABCPolyBase поскольку он больше не использовался в производных удобных классах. Это может затронуть пользователей, которые создали производные классы от ABCPolyBase и переопределили методы для представления и отображения, например __str__, __repr__, _repr_latex, и т.д.

(gh-16589)

float->timedelta и uint64->timedelta приведение вызовет TypeError#

Приведение float и timedelta последовательно вызывает TypeError. np.promote_types("float32", "m8") совпадает с np.promote_types("m8", "float32") сейчас оба вызывают TypeError. Ранее, np.promote_types("float32", "m8") возвращён "m8" что считалось ошибкой.

Uint64 и продвижение timedelta последовательно вызывает TypeError. np.promote_types("uint64", "m8") совпадает с np.promote_types("m8", "uint64") сейчас оба вызывают TypeError. Ранее, np.promote_types("uint64", "m8") возвращён "m8" что считалось ошибкой.

(gh-16592)

numpy.genfromtxt теперь правильно распаковывает структурированные массивы#

Ранее, numpy.genfromtxt не удалось распаковать, если он был вызван с unpack=True и структурированный тип данных был передан в dtype аргумент (или dtype=None был передан и был выведен структурированный тип данных). Например:

>>> data = StringIO("21 58.0\n35 72.0")
>>> np.genfromtxt(data, dtype=None, unpack=True)
array([(21, 58.), (35, 72.)], dtype=[('f0', '

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

>>> np.genfromtxt(data, dtype=None, unpack=True)
[array([21, 35]), array([58., 72.])]

(gh-16650)

mgrid, r_, и т.д. последовательно возвращают корректные выходные данные для входных данных с нестандартной точностью#

Ранее, np.mgrid[np.float32(0.1):np.float32(0.35):np.float32(0.1),] и np.r_[0:10:np.complex64(3j)] не удалось вернуть значимый вывод. Эта ошибка потенциально затрагивает mgrid, ogrid, r_, и c_ когда входные данные с типом, отличным от стандартного float64 и complex128 и эквивалентные типы Python использовались. Методы были исправлены для корректной обработки различной точности.

(gh-16815)

Логические индексы массивов с несовпадающими формами теперь правильно выдают IndexError#

Ранее, если булев индекс массива соответствовал размеру индексируемого массива, но не его форме, он некорректно разрешался в некоторых случаях. В других случаях он выдавал ошибку, но ошибка была некорректно ValueError с сообщением о трансляции вместо правильного IndexError.

Например, следующее ранее ошибочно выдавало ValueError: operands could not be broadcast together with shapes (2,2) (1,4):

np.empty((2, 2))[np.array([[True, False, False, False]])]

А следующее раньше ошибочно возвращало array([], dtype=float64):

np.empty((2, 2))[np.array([[False, False, False, False]])]

Оба теперь правильно дают IndexError: boolean index did not match indexed array along dimension 0; dimension is 2 but corresponding boolean dimension is 1.

(gh-17010)

Ошибки приведения прерывают итерацию#

При итерации с приведением значений ошибка может остановить итерацию раньше, чем раньше. В любом случае неудачная операция приведения всегда возвращала неопределённые, частичные результаты. Теперь они могут быть ещё более неопределёнными и частичными. Для пользователей NpyIter C-API такие ошибки приведения теперь будут вызывать iternext() функция для возврата 0 и прерывания итерации. В настоящее время нет API для непосредственного обнаружения такой ошибки. Необходимо проверить PyErr_Occurred(), что может быть проблематично в сочетании с NpyIter_Reset. Эти проблемы всегда существовали, но новый API может быть добавлен, если потребуется пользователями.

(gh-17029)

код, сгенерированный f2py, может возвращать юникод вместо байтовых строк#

Некоторые байтовые строки, ранее возвращаемые кодом, сгенерированным f2py, теперь могут быть юникодными строками. Это результат продолжающейся очистки от Python2 к Python3.

(gh-17068)

Первый элемент __array_interface__["data"] кортеж должен быть целым числом#

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

(gh-17241)

poly1d учитывает dtype аргумента, состоящего из нулей#

Ранее создание экземпляра poly1d с полностью нулевыми коэффициентами привело бы к приведению коэффициентов к np.float64. Это повлияло на выходной тип данных методов, которые конструируют poly1d экземпляры внутренне, такие как np.polymul.

(gh-17577)

Файл numpy.i для swig предназначен только для Python 3.#

Использование функций C-API Python 2.7 было обновлено только для Python 3. Пользователям, которым нужна старая версия, следует взять её из более старой версии NumPy.

(gh-17580)

Обнаружение типа данных void в np.array#

В вызовах с использованием np.array(..., dtype="V"), arr.astype("V"), и аналогично TypeError теперь будет корректно вызываться, если не все элементы имеют одинаковую длину void. Пример этого:

np.array([b"1", b"12"], dtype="V")

Который ранее возвращал массив с типом данных "V2" который не может представлять b"1" точно.

(gh-17706)

Изменения в C API#

The PyArray_DescrCheck макрос изменён#

The PyArray_DescrCheck макрос был обновлён с NumPy 1.16.6 до:

#define PyArray_DescrCheck(op) PyObject_TypeCheck(op, &PyArrayDescr_Type)

Начиная с NumPy 1.20, код, скомпилированный для более ранней версии, будет несовместим с API NumPy 1.20. Исправление заключается в компиляции для 1.16.6 (если выпуск NumPy 1.16 является самым старым выпуском, который вы хотите поддерживать) или в ручном встраивании макроса, заменив его новым определением:

PyObject_TypeCheck(op, &PyArrayDescr_Type)

который совместим со всеми версиями NumPy.

Размер np.ndarray и np.void_ изменён#

Размер PyArrayObject и PyVoidScalarObject структуры изменились. Следующее определение заголовка было удалено:

#define NPY_SIZEOF_PYARRAYOBJECT (sizeof(PyArrayObject_fields))

поскольку размер не должен считаться константой времени компиляции: он будет меняться для разных runtime версий NumPy.

Наиболее вероятное релевантное использование — это потенциальные подклассы, написанные на C, которые придется перекомпилировать и обновить. Пожалуйста, ознакомьтесь с документацией для PyArrayObject для получения дополнительной информации и свяжитесь с разработчиками NumPy, если вы затронуты этим изменением.

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

(gh-16938)

Новые возможности#

where именованный аргумент для numpy.all и numpy.any функции#

Аргумент ключевого слова where добавлен и позволяет учитывать только указанные элементы или подоси из массива в булевом вычислении all и any. Этот новый ключевое слово доступно для функций all и any оба через numpy напрямую или в методах numpy.ndarray.

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

where именованный аргумент для numpy функции mean, std, var#

Аргумент ключевого слова where добавлен и позволяет ограничить область в вычислении mean, std и var только для подмножества элементов. Он доступен как через numpy напрямую или в методах numpy.ndarray.

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

(gh-15852)

norm=backward, forward ключевые параметры для numpy.fft функции#

Опция ключевого аргумента norm=backward добавлен как псевдоним для None и действует как опция по умолчанию; ее использование приводит к тому, что прямые преобразования не масштабируются, а обратные преобразования масштабируются на 1/n.

Используя новую опцию аргумента ключевого слова norm=forward имеет прямые преобразования, масштабированные на 1/n и обратные преобразования не масштабируются (т.е. прямо противоположно опции по умолчанию norm=backward).

(gh-16476)

NumPy теперь типизирован#

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

  • ArrayLike: для объектов, которые могут быть приведены к массиву

  • DtypeLike: для объектов, которые могут быть приведены к типу данных

(gh-16515)

numpy.typing доступен во время выполнения#

Типы в numpy.typing теперь можно импортировать во время выполнения. Код, подобный следующему, теперь будет работать:

from numpy.typing import ArrayLike
x: ArrayLike = [1, 2, 3, 4]

(gh-16558)

Новый __f2py_numpy_version__ атрибут для модулей, сгенерированных f2py.#

Поскольку f2py выпускается вместе с NumPy, __f2py_numpy_version__ предоставляет способ отслеживания версии f2py, использованной для генерации модуля.

(gh-16594)

mypy тесты можно запустить через runtests.py#

В настоящее время запуск mypy с настроенными заглушками NumPy требует либо:

  • Установка NumPy

  • Добавление исходного каталога в MYPYPATH и связывание с mypy.ini

Оба варианта несколько неудобны, поэтому добавлен --mypy опция runtests, которая настраивает окружение за вас. Это также будет полезно в будущем для любого генератора кода типизации, поскольку гарантирует сборку проекта перед проверкой типов.

(gh-17123)

Отрицание пользовательского порядка обнаружения BLAS/LAPACK#

distutils позволяет исключать библиотеки при определении библиотек BLAS/LAPACK. Это может использоваться для удаления элемента из фазы разрешения библиотек, например, чтобы запретить библиотеки NetLIB, можно сделать:

NPY_BLAS_ORDER='^blas' NPY_LAPACK_ORDER='^lapack' python setup.py build

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

(gh-17219)

Разрешить передачу аргументов оптимизации в asv build#

Теперь можно передавать -j, --cpu-baseline, --cpu-dispatch и --disable-optimization флаги для сборки ASV, когда --bench-compare аргумент используется.

(gh-17284)

Теперь поддерживается компилятор NVIDIA HPC SDK nvfortran#

Добавлена поддержка компилятора nvfortran, версии pgfortran.

(gh-17344)

dtype опция для cov и corrcoef#

The dtype опция теперь доступна для numpy.cov и numpy.corrcoef. Он указывает, какой тип данных должен иметь возвращаемый результат. По умолчанию функции по-прежнему возвращают numpy.float64 результат.

(gh-17456)

Улучшения#

Улучшенное строковое представление для полиномов (__str__)#

Строковое представление (__str__) всех шести типов полиномов в numpy.polynomial был обновлён для вывода полинома в виде математического выражения вместо массива коэффициентов. Доступны два формата выражения полинома для всего пакета — один с использованием символов Юникода для надстрочных и подстрочных индексов, а другой — только с символами ASCII.

(gh-15666)

Удалить библиотеку Accelerate как кандидата на библиотеку LAPACK#

Apple больше не поддерживает Accelerate. Удалить его.

(gh-15759)

Массивы объектов, содержащие многострочные объекты, имеют более читаемый repr#

Если элементы массива объектов имеют repr содержащий новые строки, то обернутые строки будут выровнены по столбцам. В частности, это улучшает repr вложенных массивов:

>>> np.array([np.eye(2), np.eye(3)], dtype=object)
array([array([[1., 0.],
              [0., 1.]]),
       array([[1., 0., 0.],
              [0., 1., 0.],
              [0., 0., 1.]])], dtype=object)

(gh-15997)

Concatenate поддерживает указание выходного типа данных#

Поддержка была добавлена в concatenate для предоставления вывода dtype и casting используя ключевые аргументы. dtype аргумент не может быть предоставлен вместе с out один.

(gh-16134)

Потокобезопасные функции обратного вызова f2py#

Функции обратного вызова в f2py теперь потокобезопасны.

(gh-16519)

numpy.core.records.fromfile теперь поддерживает объекты, подобные файлам#

numpy.core.records.fromfile теперь может использовать объекты, подобные файлам, например io.BytesIO

(gh-16675)

Добавлена поддержка RPATH на AIX в distutils#

Это позволяет собрать SciPy на AIX.

(gh-16710)

Использовать компилятор f90, указанный в аргументах командной строки#

Выбор команды компилятора для Fortran Portland Group Compiler изменен в numpy.distutils.fcompiler. Это влияет только на команду компоновки. Это заставляет использовать исполняемый файл, предоставленный опцией командной строки (если предоставлена), вместо исполняемого файла pgfortran. Если исполняемый файл не предоставлен опции командной строки, по умолчанию используется исполняемый файл pgf90, который является псевдонимом для pgfortran согласно документации PGI.

(gh-16730)

Добавить объявления NumPy для Cython 3.0 и новее#

Объявления pxd для Cython 3.0 были улучшены, чтобы избежать использования устаревших функций C-API NumPy. Расширяющие модули, собранные с Cython 3.0+, которые используют NumPy, теперь могут устанавливать макрос C NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION чтобы избежать предупреждений компилятора C об использовании устаревшего API.

(gh-16986)

Сделать оконные функции точно симметричными#

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

(gh-17195)

Улучшения и изменения производительности#

Включить многоплатформенные SIMD оптимизации компилятора#

Серия улучшений инфраструктуры NumPy для подготовки к NEP-38, что можно резюмировать следующим образом:

  • Новые аргументы сборки

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

    • --cpu-dispatch чтобы указать набор дополнительных оптимизаций для диспетчеризации, значение по умолчанию — max -xop -fma4 которая включает все функции ЦП, кроме устаревших функций AMD.

    • --disable-optimization чтобы явно отключить все новые улучшения, также добавляется новый C определение компилятора #definition называется NPY_DISABLE_OPTIMIZATION который может использоваться как защита для любого SIMD-кода.

  • Продвинутый диспетчер CPU

    Гибкий кроссплатформенный диспетчер ЦП, построенный поверх Python/Numpy distutils, поддерживает все распространённые компиляторы с широким набором функций ЦП.

    Новый диспетчер требует специального расширения файла *.dispatch.c для обозначения диспетчеризуемого C источники. Эти источники могут компилироваться несколько раз, так что каждый процесс компиляции представляет определённые возможности CPU и предоставляет различные #определения и флаги, влияющие на пути выполнения кода.

  • Новый автоматически сгенерированный C-заголовок ``core/src/common/_cpu_dispatch.h``

    Этот заголовок генерируется модулем distutils ccompiler_opt, и содержит все #определения и заголовки наборов инструкций, которые были настроены через аргументы командной строки '--cpu-baseline' и '--cpu-dispatch'.

  • Новый заголовок C ``core/src/common/npy_cpu_dispatch.h``

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

  • Добавить новые атрибуты в модуль NumPy umath (уровень Python)

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

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

  • Показать поддерживаемые функции ЦП во время выполнения PytestTester

(gh-13516)

Изменения#

np.linspace на целых числах теперь использует floor#

При использовании int dtype в numpy.linspace, ранее значения float округлялись к нулю. Теперь numpy.floor используется вместо, что округляет в сторону -inf. Это изменяет результаты для отрицательных значений. Например, следующее ранее давало:

>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -2, -1, -1,  0,  0,  0,  1])

и теперь приводит к:

>>> np.linspace(-3, 1, 8, dtype=int)
array([-3, -3, -2, -2, -1, -1,  0,  1])

Предыдущий результат все еще может быть получен с помощью:

>>> np.linspace(-3, 1, 8).astype(int)
array([-3, -2, -1, -1,  0,  0,  0,  1])

(gh-16841)

На этой странице