Re: [eigen] SVD with singular matrices

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


2010/9/30 Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>:
> I highly prefer 1 over 2. Anyway we can't have 'svd' and 'jacobisvd', so at
> least the current svd should have a better name, mentionning the algo, and
> not a quality (FastSVD -> no), to be coherent with other names. Then... if
> it's that much buggy, just remove it.
>
> (2) is ugly, because it's about using two names for the same algo, and
> change the underlying algo underneath.. and even keeping a inconsistent
> naming for the "SVD". Really bad, imho.

Yes, I agree.

>
> I can do with keeping it and renaming it for consistency, but if this bug is
> so important for others, we need to either fix or remove. And.. yes, ... i
> know, when i say "we", I of course mean Benoit, sorry i can't fix that
> myself.

Sooorrry for being so slow implementing the new svd... i'm really
ashamed :-( once again, I would be happy if someone else beat me to
it, so don't refrain just because I've started looking at it!

>
> Also, as i already use the current SVD in some projet, i'd like a
> confirmation that the jacobisvd is "only" two (or 3, or constant) times
> slower. That is that they share the same complexity (as in O() notation)
> with respect to the size of matrices.

Yes, they both have cubic complexity for square matrices.

Being a R-SVD, JacobiSVD actually takes better advantage of
very-rectangular matrices (it's complexity is N^2 * P where N is the
smaller dim and P is the bigger dim).

I confirm that the last time I checked, JacobiSVD was only 2x slower
on big matrices, but that was 1 year ago.

Benoit

>
> regards,
>
> --
>
> Thomas Capricelli <orzel@xxxxxxxxxxxxxxx>
>
> http://www.freehackers.org/thomas
>
> On Thursday 30 September 2010 13:26:46 Benoit Jacob wrote:
>
>> So:
>
>>  - 1) should we just plain remove SVD and tell people to use JacobiSVD
>
>>  - 2) or should we, as said above, just internally reimplement SVD on
>
>> top of JacobiSVD ?
>
>>
>
>> I'm getting more and more in favor of 1). Like in other modules, use
>
>> explicit decomposition names. My concern is that with 2), in Eigen 3.1
>
>> we'd silently replace SVD by a faster but NOT AS RELIABLE
>
>> implementation. Dangerous!



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/