[Octave-bug-tracker] [bug #57033] Replace CXSPARSE with SPQR

[Markus Mützel]

Follow-up Comment #40, bug #57033 (project octave):

I don't have an overview over all SuiteSparse libraries we are using and how
they handle integers. So, I don't know why `octave::suitesparse_integer` is
defined the way it is. But it doesn't look like that definition is correct for
SPQR.
On the other hand, CHOLMOD has the following "define"s in its headers:

#if defined (LONGBLAS) || defined (BLAS64)
#define BLAS_INT SuiteSparse_long
#else
#define BLAS_INT int
#endif


It looks like we are following what CHOLMOD calls `BLAS_INT` with our
`octave::suitesparse_integer`. Changing the definition of
`octave::suitesparse_integer` to always match `SuiteSparse_long` would
probably break how we are using CHOLMOD.

SPQR doesn't seem to have a dedicated type for Fortran integers. It might
still be saver to check that we don't pass indices that would be too large for
Fortran. But I'm not sure if that is necessary...

I'm more worried about conversions from `SuiteSparse_long` to
`octave_idx_type` instead of the other way round because the former might have
a larger size than the latter. IIUC, `SuiteSparse_long` has at least the same
size as `octave_idx_type`.
While dense matrices of that size would probably quickly cause memory issues,
large sparse matrices might be more common...

We have `to_suitesparse_intptr` and `to_octave_idx_type_ptr` for conversions
between suitesparse_int* and octave_idx_type*. These functions throw an error
if the sizes of these integer types don't match.
We could add similar functions for conversions between SuiteSparse_long* and
octave_idx_type*. But that would mean that users would see errors if Octave's
index size wouldn't match the pointer size on their system.
IIRC, we support that configuration, do we?

When we are copying over element-by-element from SuiteSparse_long arrays to an
Octave array, a function that is similar to `to_f77_int` could be helpful
(probably checking against flintmax<double>, i.e. 2^53?).

    _______________________________________________________

Reply to this item at:

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

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