[Octave-bug-tracker] [bug #55564] GESDD: vastly different singular values when vectors are also requested

[count]

Follow-up Comment #21, bug #55564 (project octave):

The point is: GESVD is also returning wrong result for the original example.
i.e. you only gain extra precision of one or two digits after the switch to
GESVD. see (4) below, and my uploaded file #46268.

@Tim Mitchell

1. Sorry for my misleading words. Yes, I mean I'm suggesting to use GESDD as
the default driver, and keep GESVD as an alternative, and a proper
documentation in svd().

  The reason is, as I said and as you understood: (i) error=1e-15 is not too
bad; (ii) GESVD too slow for large scale problem.

  The speed is alread discussed elsewhere, but let me post one more sample.

a = randn(2000); tic; [u,s,v]=svd(a); toc;
octave, GESVD: 54.822 sec
octave, GESDD: 3.6 sec
matlab: 3.2 sec

  We gain extra (say 2 digits) precision occasionally at the cost of 10 times
slower, every time, despite of the user need it or not (assume average users
keep using the default driver). Most users will feel that Octave is slow,
instead of been more accurate.

2. For the dgesvj or dgejsv drivers. I will file a new bug.

3. Thanks for linking the SIAM Review. It helps a lot. Thanks for correcting
the relative error computations.

4. Right, GESDD returns wrong result there, but GESVD is also wrong for the
same example. The second singular value of A:

  N = 26
  formula solution = 1
  GESVD  = 3.76175e+09
  GESDD  = 6.07965e+10

Clearly, this example can't be used to demonstrate that GESVD is better than
GESDD. They are all wrong, well GESVD is less wrong by one digit.

Compared to the first singular value s_max = 6.08901e+26, they are all around
or under machine epsilon.

In the SIAM review, fig.29 and fig.30 compared the accuracy for us. The
improvement of QR (GESVD) compare to D&C (GESDD) range from zero to several
digits. I think it is not worth to switch for this small and uncertain
improvement.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55564>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/