[SciPy-user] complex vector scalar product: wrong implementation

[Robert Kern]

Vladimir A. Roudnev wrote:
> Perry Greenfield wrote:
> 
>>[...] That's why the multiply operator doesn't do matriz multiplication (many have been upset at that too). It's an array package where element-by-element operations
>>are the primary focus.  And as hard as it may be to believe, there
>>are those for which that is their primary focus.
>>  
>>
> What makes the situation essentially different for the subj, is the fact 
> that the wrong (or inadequate, whatever we call it) implementation is 
> not reflected in documentation at all. I believe, that if the bug has 
> been mentioned in the docs, people would scream out loud much earlier. I 
> still insist that this is a bug rather than a feature, possibly not an 
> easy one to fix...

In [1]: dot?
Type:           function
Base Class:     <type 'function'>
String Form:    <function dot at 0x7bb6f0>
Namespace:      Interactive
File:           /Library/Python/2.3/Numeric/dotblas/__init__.py
Definition:     dot(a, b)
Docstring:
     returns matrix-multiplication between a and b.
     The product-sum is over the last dimension of a and the
     second-to-last dimension of b.

     NB: No conjugation of complex arguments is performed.

     This version uses the BLAS optimized routines where possible.

Okay, it looks like this only got documented in the dotblas version's 
docstring and not in the manual or the regular version's docstring.

[snip]

>>If you want to contribute to 
>>improving scipy, that would be great, but understand, like anything,
>>else, there are things like this that have some history to them and
>>may not be changed just because you don't like it.
>>  
>>
> Hey, isn't this history still in our hands? Good thing about Scipy is, 
> as I understand it, it is  not a closed commercial product which would 
> be overloaded by back-compatibility problems. I see it as an attempt to 
> develop something really useful for scientific community, and 
> developer's efforts should be taken to satisfy the community needs. If 
> these needs are controversial, they must be satisfied by different 
> modules rather than leading to compromised designs. If something is done 
> wrong (as the implementation under discussion), it is better to change 
> it sooner than later. Don't you agree?
> 
> Indeed, fixing a substantial bug is not a an easy thing sometimes, but 
> the more substantial bugs we ignore, the earlier our technology dies.

For a lot of users, it is already later, not sooner. A lot of code 
depends on the current behaviour, and we would break that code by 
replacing dot with a different implementation. This is why I suggest 
adding a new function that does the inner product with conjugation for 
complex arguments.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter