Nothing I've seen so far envisages disturbing the existing, in my opinion flawed, Matrix Class.

I trust that I have not missed anything.

Compilation is a complex press for a person unfamiliar with the C.  Anything you could do to simplify that would be welcome.

Colin W.

On 12/08/2014 1:50 PM, Charles R Harris wrote:

On Tue, Aug 12, 2014 at 8:26 AM, Nathaniel Smith <> wrote:
Hi Matt,

On Mon, Aug 11, 2014 at 10:46 PM, Matti Picus <> wrote:
> Hi Nathaniel.
> Thanks for your prompt reply. I think numpy is a wonderful project, and you
> all do a great job moving it forward.
> If you ask what would my vision for maturing numpy, I would like to see a
> grouping of linalg matrix-operation functionality into a python level
> package, exactly the opposite of more tightly tying linalg into the core of
> numpy.

As I understood it (though I admit Chuck was pretty terse, maybe he'll
correct me :-)), what he was proposing was basically just a build
system reorganization -- it's much easier to call between C functions
that are in the same Python module than C functions that are in
different modules, so we end up with lots of boilerplate gunk for the
latter. I don't think it would involve any tighter coupling than we
already have in practice.

I'm trying to think of the correct sequence of moves. Here are my current thoughts.
  • Move _dotblas down into multiarray
    1. When there is cblas, add cblas implementations of decr->f->dot.
    2. Reimplement API matrixproduct2
    3. Make a first class method and use it for
  • Implement matmul
    1. Add matrixmultiply (matmul?) to the numpy API
    2. Implement __matmul__ method.
    3. Add functions to linalg for stacked vectors.
    4. Make sure __matmul__ works with __numpy_ufunc__
  • Consider using blas_lite instead of cblas, but that is now independent
    of the previous steps.


NumPy-Discussion mailing list