This function is very nice. However, it only appears to work in 2D. I realize that making it work in ND will require a lot more work, but it does seem like a good thing to have. Perhaps a recursive solution would work?

One test that I think is missing is for mismatched dtypes. Looping over all the possible combinations is perhaps overkill, but at least a check that block(intArray, floatArray) returns a float_ is probably a good idea for regression.

Besides the lack of support for >2D, I like this PR.

☔ The latest upstream changes (presumably #7268) made this pull request unmergeable. Please resolve the merge conflicts.

I've made a couple of changes. Thinking about it, I don't think we should allow block(A, B, C) notation. We do that in a couple of places in Numpy but I think the recent tendency is to simply use lists or tuples. Allowing it also makes it more difficult if we ever want to add arguments. @njsmith Thoughts?

Keeping the outer brackets also makes it look more like np.array, right? You are proposing to add back the outer brackets like

>>> np.block([a,b,c])          # 2d array  (6, 2), "column" stack
>>> np.block([[a,b,c]])        # 2d array  (2, 6), "row" stack
>>> np.block([[a],[b],[c]])    # 2d array  (6, 2), "column" stack

where o = np.ones((2,2)); a,b,c = 1*o, 2*o, 3*o. (remove outer bracket to get current behavior).

Compare that to np.array:

>>> np.array([1,2,3])        # 1d array (3,)
>>> np.array([[1,2,3]])      # 2d "row" array     (1, 3)
>>> np.array([[1],[2],[3]])  # 2d "column" array  (3, 1)

So the last two lines of each case look more alike. I'll also admit that block(a,b,c) stacking in columns was unexpected to me initially because I think of 1d arrays as rows, but I see how it might be more convenient this way because [a],[b],[c] is annoying to write.

Sorry to be late to this: my sense would be to, initially at least, limit the possible ways to do the same thing. I think visually it is much clearer if any times arrays are placed next to each other, they are in fact put next to each other in a row in the final array, never below each other in a column. So, I would
np.block([a, b, c]) be equivalent to np.hstack (with the number of braces just indicating the (minimum) number of dimensions one gets out).

Here, I like @ahaldane's analogy with the np.array -- the real difference is that each item can have its own shape. It also seems that, as @madphysicist suggested, one might as well take this to its logical conclusion, and allow any level of lists for as high n-dimensional arrays as one has the patience typing [[[[[[... for. It seems this should not be overly hard to implement by calling np.block recursively (this especially if one does not special-case [a, b, c]).

By the way, the previous mailing list discussion is at

http://thread.gmane.org/gmane.comp.python.numeric.general/58748/

There it still looks up in the air whether to include the outer brackets, but if we keep them it would mean block does the same thing as np.bmat, except in a simpler way and for ndarrays instead of matrices. Personally I probably prefer with, for the reasons above.

☔ The latest upstream changes (presumably #7985) made this pull request unmergeable. Please resolve the merge conflicts.

One more request I would like to propose (possibly for another PR), is to add this to masked arrays as well.

Will branch 1.12.x soon, so pushing this off to 1.13.

Seems like this should be done in two passes, so as to pre-allocate the destination array, rather than allocating again for each dimension

@mhvk

one might as well take this to its logical conclusion, and allow any level of lists for as high n-dimensional arrays as one has the patience typing [[[[[[... for

@charris

I don't think we should allow block(A, B, C) notation.

@madphysicist

Besides the lack of support for >2D, I like this PR.

All these points are addressed in #8886

Sorry to interrupt the discussion here, but am curious to see if this might handle a use case I have. A snippet of an example of where I might like to use block is below. Thanks for your hard work on this.

In [1]: a
Out[1]: 
array([[-10,  -2,   1],
       [  4,  -7,   6]])

In [2]: b
Out[2]: 
array([[ 5, -2,  3],
       [-3, -8,  2],
       [-7,  1, -2],
       [-9, -2, -3]])

In [3]: c
Out[3]: 
array([[-10,   8,   4,  -6,  -1],
       [  1,  -1,  -3,  -2,   6]])

In [4]: d
Out[4]: 
array([[ 1, -2,  0,  6,  1],
       [ 9, -1,  9,  5, -7],
       [-7, -7,  8, -1,  0],
       [-8,  0,  7,  3,  9]])

In [5]: np.concatenate([np.concatenate([a, c], axis=1), np.concatenate([b, d], axis=1)], axis=0)
Out[5]: 
array([[-10,  -2,   1, -10,   8,   4,  -6,  -1],
       [  4,  -7,   6,   1,  -1,  -3,  -2,   6],
       [  5,  -2,   3,   1,  -2,   0,   6,   1],
       [ -3,  -8,   2,   9,  -1,   9,   5,  -7],
       [ -7,   1,  -2,  -7,  -7,   8,  -1,   0],
       [ -9,  -2,  -3,  -8,   0,   7,   3,   9]])

In[6]: np.block([[a, c], [b, d]])
Out[6]: 
array([[-10,  -2,   1, -10,   8,   4,  -6,  -1],
       [  4,  -7,   6,   1,  -1,  -3,  -2,   6],
       [  5,  -2,   3,   1,  -2,   0,   6,   1],
       [ -3,  -8,   2,   9,  -1,   9,   5,  -7],
       [ -7,   1,  -2,  -7,  -7,   8,  -1,   0],
       [ -9,  -2,  -3,  -8,   0,   7,   3,   9]])

@jakirkham: I'm afraid you're out of luck there - dimensions are concatenated from right to left, so [a, b] will not concatenate.

Of course, if you want to concatenate from left to right, you can just transpose: np.block([[a.T, b.T], [c.T, d.T]]).T there.

You could also write it as, without much benefit over what you already have:

np.block([  # basically hstack
    np.block([[a], [b]]), np.block([[c], [d]])  # basically vstack
])

Oops, sorry, I think I had the order flipped in my example. b and c were in the wrong places. Have edited it to fix this issue. Does this now accurately reflect the behavior of block?

Yes, what you now have would work just fine

Awesome, thanks. Sorry for the confusion.

@eric-wieser I should close this, right?