[Numpy-discussion] Scipy dot
Thu Nov 8 13:38:31 CST 2012
Thanks for all the responses folks. This is indeed a nice problem to solve.
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.
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,
- 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 <firstname.lastname@example.org> wrote:
> 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).
> On Thu, Nov 8, 2012 at 12:29 PM, Anthony Scopatz <email@example.com> wrote:
>> On Thu, Nov 8, 2012 at 7:06 AM, David Cournapeau <firstname.lastname@example.org>
>>> On Thu, Nov 8, 2012 at 12:12 PM, Dag Sverre Seljebotn
>>> <email@example.com> 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
>>> NumPy-Discussion mailing list
>> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
More information about the NumPy-Discussion