You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SuiteSparse_long is similar to our Int, i.e. determined by the architecture. On 64 bit, CHOLMOD and UMFPACK let you use Cint/Int32 for the integers, but this option is not there for SPQR which call the _l_ versions of the functions. On 32 bit there is really no difference between the _l_ and the non-_l_ version, but they cannot be mixed so therefore I had to change our default such that we now call the _l_ versions whenever the chosen integer type is the same as Int. Does it make sense?
Isn't our Int always a 32 bit integer type on 32 bit systems and a 64 bit integer type on 64 bit systems just like SuiteSparse_long? I believe I'm relying on this assumption in the cholmod_name macro.
With the default configuration of suitesparse, yes. However when we're using system versions of this library we're at the mercy of how suitesparse was configured. I'd prefer we make as few assumptions as possible, and rely on the information that we actually get from the library (our wrapper, anyway) about how it was configured.
Okay. Thanks for the comments. I've changed the dependence on Int to SuiteSparse_long which is detected from the linked library. I'll push as soon as the tests pass locally.
7 commit comments
tkelman commentedon Feb 16, 2015
This looks completely backwards
andreasnoack commentedon Feb 16, 2015
The
SuiteSparse_long
is similar to ourInt
, i.e. determined by the architecture. On 64 bit, CHOLMOD and UMFPACK let you useCint/Int32
for the integers, but this option is not there for SPQR which call the_l_
versions of the functions. On 32 bit there is really no difference between the_l_
and the non-_l_
version, but they cannot be mixed so therefore I had to change our default such that we now call the_l_
versions whenever the chosen integer type is the same asInt
. Does it make sense?tkelman commentedon Feb 16, 2015
I think so, but please include this kind of information in the commit message, comments, or both.
Mostly. It's set to
long
on all architectures except for Win64, where it's set to__int64
. I don't believe we're overwriting this behavior anywhere.andreasnoack commentedon Feb 16, 2015
Isn't our
Int
always a 32 bit integer type on 32 bit systems and a 64 bit integer type on 64 bit systems just likeSuiteSparse_long
? I believe I'm relying on this assumption in thecholmod_name
macro.tkelman commentedon Feb 16, 2015
With the default configuration of suitesparse, yes. However when we're using system versions of this library we're at the mercy of how suitesparse was configured. I'd prefer we make as few assumptions as possible, and rely on the information that we actually get from the library (our wrapper, anyway) about how it was configured.
andreasnoack commentedon Feb 16, 2015
Okay. Thanks for the comments. I've changed the dependence on
Int
toSuiteSparse_long
which is detected from the linked library. I'll push as soon as the tests pass locally.ViralBShah commentedon Feb 16, 2015
This is certainly a better way to go about it.