weirdness of Dec alphas

[John W. Eaton]

On 27-Oct-2000, Ross Lippert <address@hidden> wrote:

| this might be an alpha bug or a g77 bug and not an octave
| bug, but has anyone seen this:
| 
| octave:1> svd([-5 5;5 -5])
|  ** On entry to DGESVD parameter number 13 had an illegal value
| error: exception encountered in Fortran subroutine dgesvd
| error: unrecoverable error in dgesvd
| octave:1> 
| 
| > uname
| OSF1
| 
| I'd send my config.h but it is on a system behind a firewall which
| isn't very friendly at all (I can't ftp through it).  The fortran
| compiler is g77, and the C/C++ compilers are GNU:
| > g77 --version
| GNU Fortran 0.5.25 19991024 (release)
| > g++ --version
| 2.95.2

Looking at dgesvd.f, arg 13 is the length of the work vector.  In
dbleSVD.cc, we find:

  // Ask DGESVD what the dimension of WORK should be.

  int lwork = -1;

  Array<double> work (1);

  F77_XFCN (dgesvd, DGESVD, (&jobu, &jobv, m, n, tmp_data, m, s_vec,
                             u, m, vt, nrow_vt, work.fortran_vec (),
                             lwork, info, 1L, 1L));

This change was made when a new version of lapack was released that
allowed this to work.  My guess is that you are calling an older
version of this function from some library that is not distributed
with Octave.

I don't know what to do about this, but it will surely be annoying,
because probably more than a few people will encounter this problem.
I'd really prefer not to go back to the old way of computing the work
vector length in Octave, because that has the problem that the
required length can be different from one version of the library to
the next.

jwe