Я использую итерацию функции значения для решения сложной задачи динамического программирования со многими состояниями. Я хочу использовать numba/jit для ускорения моего кода (и, в конечном итоге, для распараллеливания циклов for). Когда я использую декоратор @jit
в своем коде, я получаю ошибку nopython
, хотя я не вызываю режим nopython
.
@jit
def vfi(cm, λ=1):
vf_new = np.zeros_like(cm.vf)
k_prime = np.zeros_like(cm.k_opt)
for k_i in range(cm.k_grid_size):
cm.set_k(cm.kgrid[k_i])
for b_i in range(cm.cb_grid_size):
cm.set_b(cm.cb_mesh[0][b_i])
for s_i in range(2):
cm.set_s(s_i)
b_prime = cm.b_prime(cm.kgrid)
vf_interp = RegularGridInterpolator((cm.kgrid, cm.cb_mesh[0],cm.sgrid), cm.vf)
objective = cm.F - cm.T(cm.kgrid) - cm.C(cm.kgrid) + cm.β*cm.p*np.array([vf_interp(x) for x in zip(cm.kgrid,b_prime,np.zeros_like(b_prime))]) + cm.β*(1-cm.p)*np.array([vf_interp(x) for x in zip(cm.kgrid,b_prime,np.ones_like(b_prime))])
vf_new[k_i,b_i,s_i] = np.max(objective)
k_prime[k_i,b_i,s_i] = np.argmax(objective)
error = np.max(np.abs(cm.vf - vf_new))
cm.vf = cm.vf + λ*(vf_new-cm.vf)
cm.k_opt = k_prime
return error
qe.util.tic()
cm = CarrybacksModel()
error = 10000000
itern=0
tol = 1e-5
while error>tol:
error = vfi(cm)
itern+=1
print(f"Iteration number {itern}, error = {error}.")
print(f"Completed in {itern} iterations.")
qe.util.toc()
Возвращает следующую ошибку:
> ---------------------------------------------------------------------------
TypingError Traceback (most recent call last)
Cell In[57], line 7
5 tol = 1e-5
6 while error>tol:
----> 7 error = vfi(cm)
8 itern+=1
9 print(f"Iteration number {itern}, error = {error}.")
File ~\miniconda3\Lib\site-packages\numba\core\dispatcher.py:468, in _DispatcherBase._compile_for_args(self, *args, **kws)
464 msg = (f"{str(e).rstrip()} \n\nThis error may have been caused "
465 f"by the following argument(s):\n{args_str}\n")
466 e.patch_message(msg)
--> 468 error_rewrite(e, 'typing')
469 except errors.UnsupportedError as e:
470 # Something unsupported is present in the user code, add help info
471 error_rewrite(e, 'unsupported_error')
File ~\miniconda3\Lib\site-packages\numba\core\dispatcher.py:409, in _DispatcherBase._compile_for_args.<locals>.error_rewrite(e, issue_type)
407 raise e
408 else:
--> 409 raise e.with_traceback(None)
TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Untyped global name 'RegularGridInterpolator': Cannot determine Numba type of <class 'type'>
File "..\..\..\..\AppData\Local\Temp\ipykernel_16688\910653365.py", line 12:
<source missing, REPL/exec in use?>
This error may have been caused by the following argument(s):
- argument 0: Cannot determine Numba type of <class '__main__.CarrybacksModel'>
Я знаю, что не могу использовать режим njit/nopython, поскольку я определяю свой собственный класс, а scipy RegularGridInterpolator
кажется несовместимым. Однако я подумал, что если использовать декоратор @jit
вместо @njit
, то nopython
никогда не следует вызывать. Почему я получаю ошибку nopython
?
При необходимости я готов использовать другую функцию вместо RegularGridInterpolator
— я сам написал ее и украсил ее @jit
, но все равно получил ту же ошибку.
Я думаю, что режим nopython используется по умолчанию.
Из Decorators.py в репозитории numba github:
if nopython is False:
msg = ("The keyword argument 'nopython=False' was supplied. From "
"Numba 0.59.0 the default is True and supplying this argument "
"has no effect.")
Я думаю, что вариант, который вы ищете для принудительного перехода в режим Python, называется forceobj
.
Это верно, использование Forceobj решило проблему! Спасибо
Обратите внимание, что Numba здесь практически бесполезен. Это может только ускорить циклы, но циклы явно не должны быть узким местом в этом коде. В objmode вызовы/доступы Numpy не оптимизированы. Фактически, что делает Numba быстрым, так это знание типов всех переменных и использование собственных. Если одна переменная является объектом, то Numba не сможет генерировать собственный ассемблерный код и перейти к медленному режиму чистого Python с немного более быстрыми циклами. В таком случае Cython более полезен, поскольку вы можете, по крайней мере, указать типы для части объектов, чтобы частично ускорить вычисления.