You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 2, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 2, 2024. It is now read-only.
Invalid result for HO function with bound instancemethod argument #63
Numba does partially support higher-order functions and local closures, but the boundaries are not clearly defined as well as the inlining effect on it.
For HPAT, code below actually results in invalid results and no JIT compilation time error.
We should fix this bug and properly document what kinds of callable values HPAT supports.
After that, it would be simpler to give proper error messages to the user.
Right now it's unclear what are should be compiled and what should result in a compilation error.
Reproducer:
importhpatimportpandasaspd# Higher-order function@hpat.jitdefindirect(call, fn):
ifcall:
returnfn()
return0@hpat.jitdefweird():
df=pd.DataFrame({'A': [1]})
returnindirect(False, df.head)
# This one works fine@hpat.jitdefindirect_ok(fn):
returnfn()
@hpat.jitdefworks_as_expected():
df=pd.DataFrame({'A': [1]})
returnindirect_ok(df.head)
print(weird())
print(works_as_expected())
HPAT has an inline pass that inlines other jit functions. With inlining in place, I don't think these example will have higher order function call.
However, this pass was a quick hack for a use case written long time ago and definitely needs to be revisited. For example, it might not set the IR definitions data structures properly.
I looked at these examples some more. Looks like inlining is fine. For the top example, the weird function has a type unification issue, since either a dataframe (from df.head) or 0 is assigned to a variable based on a conditional. This will be caught when we make the hiframes pass a typed pass (the current pass has no way of knowing).
I think the a.sum example triggers a bug in Numba's parfor preprocessing stage where a.sum should be converted to np.sum(a) but looks like the call doesn't have the array argument.
Numba does partially support higher-order functions and local closures, but the boundaries are not clearly defined as well as the inlining effect on it.
For HPAT, code below actually results in invalid results and no JIT compilation time error.
We should fix this bug and properly document what kinds of callable values HPAT supports.
After that, it would be simpler to give proper error messages to the user.
Right now it's unclear what are should be compiled and what should result in a compilation error.
Reproducer:
Results for code without
@hpat.hitdecorator:Results for code with JIT: