incoherent behaviour with prange
See original GitHub issueFirst, thanks a lot for this very useful job !
Here is the problem: I slightly change the example of prange given in the documentation and get a very strange behaviour. Here is my code
from numba import njit, prange
@njit(parallel=True)
def prange_test(A, cond):
s = 0
for i in prange(A.shape[0]):
if cond[i]:
s += 1
return s
Here are my inputs
A = np.random.randint(0,10,100)
cond = np.random.randint(0,2,len(A)).astype('bool')
In this case scenario changing njit option from True to False do not affect the result of prange_test(A, cond) (which is what I expect)
However, setting s=1 as a starting condition in prange_test() definition make prange_test(A, cond) results to be different depending of the parallel value !
If parallel==False, the result is ok; If parallel==True, the results is larger of the quantity: 1 x number_threads +1.
Setting s=2 as a starting condition in prange_test() definition makes the result to be larger of quantity 2 x number_of_threads +2.
This strange behavior disappears if there is no check of the cond value in prange_test(A, cond) (it returns the length of A+initial s value) whatever the initial value of s
It seems inconsistent as it gives wrong results and threads dependent. I do not understand why checking ``cond’ creates inconsistencies.
Thanks for the help !
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (3 by maintainers)

Top Related StackOverflow Question
@lanougue For a quick fix, try the following. I know it shouldn’t matter if you do s = 1 at the beginning or s+= 1 at the end but given the bug it does matter. We can do something here for += and *= but for more esoteric operators we may not know the identity value and so have to use the initial value as the identity value. The bug is that in this case it doesn’t recognize the operator as addition and so doesn’t know the identity is 0 and so using the previous value of the variable. The complex reason is that there’s a hidden array of reduction values (each worker gets its own) and that array is currently initialized with the value of the reduction variable when entering the loop but that needs to be the identity value.
Thanks for the workaround, I will give a look. Thanks for the reactivity !
Whoever wants to look at this numba bug is welcome. My python level is clearly not good enough for that ! 😉