[Numpy-discussion] Scipy dot

Nicolas SCHEFFER scheffer.nicolas at gmail.com
Thu Nov 8 14:38:31 EST 2012


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 <nouiz at nouiz.org> 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 <scopatz at gmail.com> wrote:
>>
>> On Thu, Nov 8, 2012 at 7:06 AM, David Cournapeau <cournape at gmail.com>
>> wrote:
>>>
>>> On Thu, Nov 8, 2012 at 12:12 PM, Dag Sverre Seljebotn
>>> <d.s.seljebotn at astro.uio.no> 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
>>> NumPy-Discussion at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



More information about the NumPy-Discussion mailing list