Charles,
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 <njs@pobox.com mailto:njs@pobox.com> wrote:
Hi Matt, On Mon, Aug 11, 2014 at 10:46 PM, Matti Picus <matti.picus@gmail.com <mailto:matti.picus@gmail.com>> 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
- When there is cblas, add cblas implementations of decr->f->dot.
- Reimplement API matrixproduct2
- Make ndarray.dot a first class method and use it for numpy.dot.
- Implement matmul
- Add matrixmultiply (matmul?) to the numpy API
- Implement __matmul__ method.
- Add functions to linalg for stacked vectors.
- Make sure __matmul__ works with __numpy_ufunc__
- Consider using blas_lite instead of cblas, but that is now independent of the previous steps.
<snip>
Chuck
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion