Thanks for all the responses folks. This is indeed a nice problem to solve.
Few points: I. Change the order from 'F' to 'C': I'll look into it. II. Integration with scipy / numpy: opinions are diverging here. Let's wait a bit to get more responses on what people think. One thing though: I'd need the same functionality as get_blas_funcs in numpy. Since numpy does not require lapack, what functions can I get? III. Complex arrays I unfortunately don't have enough knowledge here. If someone could propose a fix, that'd be great. IV. C Writing this in C sounds like a good idea. I'm not sure I'd be the right person to this though. V. Patch in numpy I'd love to do that and learn to do it as a byproduct. Let's make sure we agree this can go in numpy first and that all FIXME can be fixed. Although I guess we can resolve fixmes using git. Let me know how you'd like to proceed, Thanks! FIXMEs: - Fix for ndim != 2 - Fix for dtype == np.complex* - Fix order of output array On Thu, Nov 8, 2012 at 9:42 AM, Frédéric Bastien <[email protected]> wrote: > Hi, > > I also think it should go into numpy.dot and that the output order should > not be changed. > > A new point, what about the additional overhead for small ndarray? To remove > this, I would suggest to put this code into the C function that do the > actual work (at least, from memory it is a c function, not a python one). > > HTH > > Fred > > > > On Thu, Nov 8, 2012 at 12:29 PM, Anthony Scopatz <[email protected]> wrote: >> >> On Thu, Nov 8, 2012 at 7:06 AM, David Cournapeau <[email protected]> >> wrote: >>> >>> On Thu, Nov 8, 2012 at 12:12 PM, Dag Sverre Seljebotn >>> <[email protected]> wrote: >>> > On 11/08/2012 01:07 PM, Gael Varoquaux wrote: >>> >> On Thu, Nov 08, 2012 at 11:28:21AM +0000, Nathaniel Smith wrote: >>> >>> I think everyone would be very happy to see numpy.dot modified to do >>> >>> this automatically. But adding a scipy.dot IMHO would be fixing >>> >>> things >>> >>> in the wrong place and just create extra confusion. >>> >> >>> >> I am not sure I agree: numpy is often compiled without lapack support, >>> >> as >>> >> it is not necessary. On the other hand scipy is always compiled with >>> >> lapack. Thus this makes more sens in scipy. >>> > >>> > Well, numpy.dot already contains multiple fallback cases for when it is >>> > compiled with BLAS and not. So I'm +1 on just making this an >>> > improvement >>> > on numpy.dot. I don't think there's a time when you would not want to >>> > use this (provided the output order issue is fixed), and it doesn't >>> > make >>> > sense to not have old codes take advantage of the speed improvement. >>> >>> Indeed, there is no reason not to make this available in NumPy. >>> >>> Nicolas, can you prepare a patch for numpy ? >> >> >> +1, I agree, this should be a fix in numpy, not scipy. >> >> Be Well >> Anthony >> >>> >>> >>> David >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> [email protected] >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
