У меня только что была эта проблема. Ни intent(inout)
, ни intent(inplace)
не исправили это. Проблема, очевидно, заключается в процедуре проверки массива array_from_pyobj()
в fortranobject.c
, которая поставляется с f2py
и связана с каждым модулем, который он строит. array_from_pyobj()
прилагает все усилия, чтобы любые входные данные были преобразованы в непрерывный массив правильной формы, выполняя множество проверок. Один из них не работает должным образом с одноэлементными массивами, так что вместо работы с исходным массивом создается копия.
Это можно исправить, но ... ну ... я не хочу, чтобы все эти полиморфизмы в интерфейсе с библиотекой производительности в любом случае ... У меня есть класс Python, оборачивающий вызовы библиотеки, который уже гарантирует, что все аргументы переданы правильно.
Итак, я решил сделать свою собственную копию fortranobject.c
и просто заменить array_from_pyobj()
следующей фиктивной версией:
extern PyArrayObject *
array_from_pyobj(const int type_num, npy_intp *dims,
const int rank, const int intent, PyObject *obj) {
int i;
PyArrayObject *arr = (PyArrayObject *)obj;
for (i=0; i<arr->nd; ++i)
dims[i] = arr->dimensions[i];
return arr;
}
Я планирую использовать исходный fortranobject.c
во время разработки моего класса-обертки Python, где, по общему признанию, преимущество заключается в том, чтобы получать мягкие сообщения об ошибках вместо серьезных сбоев каждый раз, когда совершается ошибка при вызове функции библиотеки. Как только я буду уверен, что все вызовы библиотеки работают, я буду использовать свой собственный fortranobject.c
, который также работает с одноэлементными массивами.