weirdness of Dec alphas

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

weirdness of Dec alphas

Ross Lippert-2



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



-r


Reply | Threaded
Open this post in threaded view
|

weirdness of Dec alphas

John W. Eaton-6
On 27-Oct-2000, Ross Lippert <[hidden email]> 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