Hey, there are several ways how to proceed.
- My proposed solution covers the 80% case quite well (at least I use it all the time). I'd convert the doctests into unittests and we're done. - We could slightly change the interface to leave out the surrounding square brackets, i.e. turning `stack([[a, b], [c, d]])` into `stack([a, b], [c, d])` - We could extend it even further allowing a "filler value" for non set values and a "shape" argument. This could be done later as well. - `bmat` is not really matrix specific. We could refactor `bmat` a bit to use the same logic in `stack`. Except the `matrix` calls `bmat` and `_from_string` are pretty agnostic to the input. I'm in favor of the first or last approach. The first: because it already works and is quite simple. The last: because the logic and tests of both `bmat` and `stack` would be the same and the feature to specify a string representation of the block matrix is nice. Best, Stefan On Tue, Oct 28, 2014 at 7:46 PM, Nathaniel Smith <n...@pobox.com> wrote: > On 28 Oct 2014 18:34, "Stefan Otte" <stefan.o...@gmail.com> wrote: >> >> Hey, >> >> In the last weeks I tested `np.asarray(np.bmat(....))` as `stack` >> function and it works quite well. So the question persits: If `bmat` >> already offers something like `stack` should we even bother >> implementing `stack`? More code leads to more >> bugs and maintenance work. (However, the current implementation is >> only 5 lines and by using `bmat` which would reduce that even more.) > > In the long run we're trying to reduce usage of np.matrix and ideally > deprecate it entirely. So yes, providing ndarray equivalents of matrix > functionality (like bmat) is valuable. > > -n > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion