I've made the necessary changes to get the proper order for the output array. Also, a pass of pep8 and some tests (fixmes are in failing tests) http://pastebin.com/M8TfbURi
-n On Thu, Nov 8, 2012 at 11:38 AM, Nicolas SCHEFFER <[email protected]> wrote: > 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
