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

[Markus Mützel]

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

It turned out that bug #59833 was caused by the issue discussed here in the
last comments.

After the change from comment #44, Octave successfully compiles on 64bit
systems when it was configured with `--disable-64`. However, `qr` fails with
error -4 (CHOLMOD_INVALID /* failure: invalid input */).

It turns out SPQR *requires* the integer type to be long:
https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/SPQR/Include/spqr.hpp#L125

// Return if Common is NULL or invalid
#define RETURN_IF_NULL_COMMON(result) \
{ \
    if (cc == NULL) \
    { \
        return (result) ; \
    } \
    if (cc->itype != ITYPE || cc->dtype != DTYPE) \
    { \
        cc->status = CHOLMOD_INVALID ; \
        return (result) ; \
    } \
}


Where ITYPE is unconditionally defined to CHOLMOD_LONG:
https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/SPQR/Include/spqr.hpp#L95

Atm, I see the following options:
0 Copy over all integers to arrays of the correct type and use the cholmod
functions for long integers unconditionally (instead of the ones matching
Octave's integer type using `CHOLMOD_NAME`). Copy the result back over to
Octave's integer type (performing the necessary checks).
0 Don't use SPQR if Octave uses 32bit indices on 64bit systems. Fall back to
CXSparse instead.
0 Leave it as is (after the compilation bug is fixed). I.e., display the error
if the user calls `qr` and we try to use SPQR. That would mean that `qr` would
cease to be able to solve some input it was previously able to solve.

    _______________________________________________________

Reply to this item at:

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

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