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

[val]

I agree with Robert, and i don't see any "design issues" with scipy.
It is a working tool, not a "vector space code".  If one understands
her/his data and *what* needs to be done with the data, that's it.
Python and scipy are flexible enough to satisfy any reasonable and
specific needs.  But any clarification to the docs is always welcome.
I guess my point is: Enjoy life and scipy, and/or contribute in its
improvement
optimistical-ly y'rs,
val

----- Original Message -----
From: "Vladimir Roudnev" <vroudnev at ksu.edu>
To: "SciPy Users List" <scipy-user at scipy.net>
Sent: Monday, January 10, 2005 3:52 PM
Subject: Re: [SciPy-user] complex vector scalar product: wrong
implementation


> Robert Kern wrote:
>
> >>              innerproduct(z1,z2)==conjugate(innerproduct(z2,z1))
> >> Scipy implementation, however, does not satisfy this property, what
> >> can lead to serious complications when adapting real vector
> >> algorithms to complex arithmetics. In particular, the existing
> >> implementation breaks the complex vector space metric [...]
> >
> > [...]If you are doing serious linear algebra with complex matrices
> > (and not everyone who uses innerproduct on complex arrays does), I
> > suggest you write a function that does the appropriate conjugation.
> >
> > def cdot(a, b):
> >     return dot(conjugate(a), b)
>
> Indeed, one can write the function, but my message was that the
> misimplemented scalar product is a major Scipy library DESIGN ISSUE. I
> am not even talking about the perfomance. The structure of a good
> program must reflect the structure of the problem it solves, this is the
> basic structure programming principle. It is the structure of the Scipy
> linear algebra library that does not reflect the structure of linear
> algebraic problems in general, and cheating with writing functions at
> the user level does not fix it. A real vector space code should work
> flawlessly with complex vector spaces  when the algorithm is applicable,
> isn't it in the Python programming spirit? Otherwise we end up with
> programming good old Fortran 77. (Or Fortran 777, if you wish ;) )
>
> BW,
>   VR
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
>