Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should SVD should return U,S,V' or U,S,V #912

Closed
ViralBShah opened this issue Jun 3, 2012 · 13 comments
Closed

Should SVD should return U,S,V' or U,S,V #912

ViralBShah opened this issue Jun 3, 2012 · 13 comments
Labels
breaking This change will break code
Milestone

Comments

@ViralBShah
Copy link
Member

LAPACK returns V', which is what julia returns currently. Should it return V instead? Unless there is a clear reason, I would prefer not doing the extra transpose in svd.

@ghost ghost assigned alanedelman Jun 3, 2012
@ViralBShah
Copy link
Member Author

cc @alanedelman

@timholy
Copy link
Member

timholy commented Jun 30, 2012

For reasons of performance and Matlab compatibility, I vote with keep the current behavior.

Matlab:

help svd
svd Singular value decomposition.
[U,S,V] = svd(X) produces a diagonal matrix S, of the same
dimension as X and with nonnegative diagonal elements in
decreasing order, and unitary matrices U and V so that
X = U_S_V'.

(They really should have named that matrix Vt or Vp in their documentation!)

@JeffBezanson
Copy link
Member

No, matlab does it the other way. We return V', while matlab returns V such that X=U*S*V'.

@timholy
Copy link
Member

timholy commented Jun 30, 2012

Ah. Thanks for explaining.

In general I'm in favor of doing less (i.e., return whatever LAPACK gives us), but the Matlab compatibility would be an issue for people migrating over.

@StefanKarpinski
Copy link
Member

I think we should do the Matlab-compatible version even though I generally find it annoying. It's also the more mathematically correct form since that's how the factorization is always written (so that U and V are both column-orthonormal, rather than V being row-orthonormal). It's kind of annoying though since I frequently transpose V immediately.

@StefanKarpinski
Copy link
Member

I propose that we define svdt that returns V' and for now we can define svd in terms of that.

@timholy
Copy link
Member

timholy commented Jun 30, 2012

I like it.

@JeffBezanson
Copy link
Member

But we may end up modifying lapack, in which case we won't be able to compute both svd and svdt efficiently. And if multiplication by the transpose is wanted we're better off writing X*V' so we make the right BLAS call.

@alanedelman
Copy link
Contributor

i like stephan's answer
and i'm hoping we realize that this is a minor alternative
to lapack
i suspect 10 minutes of thought would convince us we have to multiply
householders right to left instead of left to right, but i haven't given it
the five minutes of thought

On Fri, Jul 6, 2012 at 4:48 AM, Jeff Bezanson <
reply@reply.github.com

wrote:

But we may end up modifying lapack, in which case we won't be able to
compute both svd and svdt efficiently. And if multiplication by the
transpose is wanted we're better off writing X*V' so we make the right
BLAS call.


Reply to this email directly or view it on GitHub:
#912 (comment)

@StefanKarpinski
Copy link
Member

The X*V' doesn't actually need a transpose in any case. When/if we modify LAPACK for this, we can either just implement svd in terms of svdt, or allow a stride parameter in the outputs, or have two different routines.

@ViralBShah
Copy link
Member Author

Decision is to have svd and svdt. Tests will then need to be updated, and we should ensure the same is done for svds.

@StefanKarpinski
Copy link
Member

To clarify svd returns (U,S,V) like Matlab and svdt returns (U,S,V') like LAPACK. That means that svd does a transpose even though it doesn't return V transposed.

@ViralBShah
Copy link
Member Author

Closed by commit afcace2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code
Projects
None yet
Development

No branches or pull requests

5 participants