[Octave-bug-tracker] [bug #29487] Feature request: svd with 3 output variables should use dgesdd

[Jaroslav Hajek]

Follow-up Comment #7, bug #29487 (project octave):

I can't really agree, John, I think you're overgeneralizing.
99.9% of svd-based functions can't tell which driver they need, because it
depends on the input data, and to reliably discover ill-conditioned matrices
you generally need to svd them first. I believe this more or less holds for
all svd-based functions in Octave's library, as well as OctaveForge packages
and the rest of the world. That's where it differs from global variables that
affect technical details, such as sparse_auto_mutate, which really is bad (and
I'd vote for removing it, but that's a different matter).

So, if we provide an extra function, we won't be changing anything else to
stay on the safe side, so users won't see any difference in svd-based
functions, although they will be able to use svddc in their own scripts.

As you said yourself, most users (incl. me) will want to "just try" the new
driver to possibly get the results faster. For their own scripts, both
solutions are OK, but when they use other svd-based functions (such as the
popular leasqr), svd_method is far more convenient than having to create
@double/svd (and possibly also @single/svd) overloads.
Not speaking about the fact that it's a little tricky to write the overloads
correctly (even you didn't do it quite right, watch out for nargout=0 case).

The solutions are interchangeable both ways, actually:
Just like you can override the library svd with svddc, you can also write
svddc using unwind_protect + svd_method.
We can even distribute svddc with Octave, if you think it's worth the
trouble.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29487>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/