CODEWITHSUNDEEP
pythonnumpytypesnumbanumba-pro
user961627
user961627

Reputation: 12747

TypeError: Arrays must have consistent types in assignment

Following up from here, I've got code like the following:

@jit(float_[:,:,:](float_[:,:], int_[:], int_)) 
def train_function(X, y, H):
    # do lots of stuff, including setting the arrays g and g_per_round like this:
    g = np.zeros((no_features, no_classes))
    g_per_round = np.zeros((H, no_features, no_classes))

    # do more stuff, then:    
        g_h = None
        j = 0
        print "Calculating regression coefficients per class. .."
        # building the parameters per j class
        for y1_w in zip(z.T, weights.T):
            y1, w = y1_w 
            temp_g = sm.WLS(y1, X, w).fit()  # Step 2(a)(ii)
            if g_h is None: # sometimes g *is* None, and that's fine
                   g_h = temp_g.params # this is an array of floats
            else:
                    g_h = np.c_[g_h, temp_g.params]
            j = j + 1

        if np.allclose(g,0) or g is None:
            g = g_h
        else:            
            g = g + g_h 

    # do lots more stuff, then finally:
    return g_per_round

class GentleBoostC(object):
    # init functions and stuff
    def train(self, X, y, H):
        self.g_per_round = train_function(X, y, H)

Now I'm getting the following error:

 @jit(float_[:,:,:](float_[:,:], int_[:], int_))
 more lines, etc etc etc, last few lines:
    unresolved_types, var_name)
  File "C:\Users\app\Anaconda\lib\site-packages\numba\typesystem\ssatypes.py", line 767, in promote_arrays
    assert_equal(non_array_types[0])
  File "C:\Users\app\Anaconda\lib\site-packages\numba\typesystem\ssatypes.py", line 764, in assert_equal
    var_name, result_type, other_type))
TypeError: Arrays must have consistent types in assignment for variable 'g': 'float64[:, :]' and 'none'

I actually had no issues with this before trying to add @jit to speed up my code.

Upvotes: 1

Views: 116

Answers (2)

Francis Avila
Francis Avila

Reputation: 31621

The problem is that numba cannot know that g_h will not be None when it is finally assigned to g because the type of g_h depends on runtime flow control. In other words, if g_h could ever not be a float64, then it has to assume that sometimes isn't.

This is a documented limitation of numba and a limitation of type inference systems in general:

However, there are some restrictions, namely that variables must have a unifyable type at control flow merge points. For example, the following code will not compile:

@jit def incompatible_types(arg):
    if arg > 10:
        x = "hello"
    else:
        x = 1

    return x        # ERROR! Inconsistent type for x!

The solution is to initialize g_h to a compatible type instead of = None.

Numba's type inference is actually quite smart so you can mix types on a particular local variable without problems in many cases as long as the type can be unified before return. Read Numba documentation on types for more info.

Upvotes: 2

robbrit
robbrit

Reputation: 17960

The issue is that Numba is inferring g_h to be NoneType; initialize it to a vector and it will compile it properly:

g_h = np.zeroes((H, no_features, no_classes))

Upvotes: 2

Related Questions