Mercurial > hg > octave-terminal
changeset 9391:333b31ce3434
eigs-base.cc: use octave_idx_type for Fortran LOGICAL values
author | Alexander Barth <barth.alexander@gmail.com> |
---|---|
date | Wed, 24 Jun 2009 13:47:22 -0400 |
parents | 288d5794eac8 |
children | 26c72e899228 |
files | liboctave/ChangeLog liboctave/eigs-base.cc |
diffstat | 2 files changed, 40 insertions(+), 31 deletions(-) [+] |
line wrap: on
line diff
--- a/liboctave/ChangeLog +++ b/liboctave/ChangeLog @@ -1,3 +1,12 @@ +2009-06-24 Alexander Barth <barth.alexander@gmail.com> + + * eigs-base.cc (EigsRealSymmetricMatrix, + EigsRealSymmetricMatrixShift, EigsRealSymmetricFunc, + EigsRealNonSymmetricMatrix, EigsRealNonSymmetricMatrixShift, + EigsRealNonSymmetricFunc, EigsComplexNonSymmetricMatrix, + EigsComplexNonSymmetricMatrixShift, EigsComplexNonSymmetricFunc): + Use octave_idx_type for parameters of type LOGICAL in ARPACK. + 2009-06-22 Jaroslav Hajek <highegg@gmail.com> * chMatrix.cc (charMatrix::charMatrix (const string_vector&)):
--- a/liboctave/eigs-base.cc +++ b/liboctave/eigs-base.cc @@ -64,7 +64,7 @@ F77_RET_T F77_FUNC (dseupd, DSEUPD) (const int&, F77_CONST_CHAR_ARG_DECL, - int*, double*, double*, + octave_idx_type*, double*, double*, const octave_idx_type&, const double&, F77_CONST_CHAR_ARG_DECL, const octave_idx_type&, F77_CONST_CHAR_ARG_DECL, const octave_idx_type&, @@ -87,7 +87,7 @@ F77_RET_T F77_FUNC (dneupd, DNEUPD) (const int&, F77_CONST_CHAR_ARG_DECL, - int*, double*, double*, + octave_idx_type*, double*, double*, double*, const octave_idx_type&, const double&, const double&, double*, F77_CONST_CHAR_ARG_DECL, const octave_idx_type&, F77_CONST_CHAR_ARG_DECL, @@ -111,7 +111,7 @@ F77_RET_T F77_FUNC (zneupd, ZNEUPD) (const int&, F77_CONST_CHAR_ARG_DECL, - int*, Complex*, Complex*, + octave_idx_type*, Complex*, Complex*, const octave_idx_type&, const Complex&, Complex*, F77_CONST_CHAR_ARG_DECL, const octave_idx_type&, F77_CONST_CHAR_ARG_DECL, @@ -984,14 +984,14 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); - + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); + eig_vec.resize (n, k); double *z = eig_vec.fortran_vec (); @@ -1321,13 +1321,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); eig_vec.resize (n, k); double *z = eig_vec.fortran_vec (); @@ -1579,13 +1579,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); eig_vec.resize (n, k); double *z = eig_vec.fortran_vec (); @@ -1898,13 +1898,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); Matrix eig_vec2 (n, k + 1); double *z = eig_vec2.fortran_vec (); @@ -2277,13 +2277,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); Matrix eig_vec2 (n, k + 1); double *z = eig_vec2.fortran_vec (); @@ -2582,13 +2582,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); Matrix eig_vec2 (n, k + 1); double *z = eig_vec2.fortran_vec (); @@ -2945,13 +2945,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); eig_vec.resize (n, k); Complex *z = eig_vec.fortran_vec (); @@ -3285,13 +3285,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); eig_vec.resize (n, k); Complex *z = eig_vec.fortran_vec (); @@ -3549,13 +3549,13 @@ // We have a problem in that the size of the C++ bool // type relative to the fortran logical type. It appears - // that fortran uses 4-bytes per logical and C++ 1-byte + // that fortran uses 4- or 8-bytes per logical and C++ 1-byte // per bool, though this might be system dependent. As // long as the HOWMNY arg is not "S", the logical array // is just workspace for ARPACK, so use int type to // avoid problems. - Array<int> s (p); - int *sel = s.fortran_vec (); + Array<octave_idx_type> s (p); + octave_idx_type *sel = s.fortran_vec (); eig_vec.resize (n, k); Complex *z = eig_vec.fortran_vec ();