Skip to content

Matrix library, CHOLMOD error: problem too large

3 messages · Jose Quesada, Duncan Murdoch, Martin Maechler

#
I have a pretty large sparse matrix of integers:
[1] 91650 37651

I need to add one to it in order to take logs, but I'm getting the  
following error:
CHOLMOD error: problem too large
Error in asMethod(object) : Cholmod error `problem too large'

I have 2 Gb of RAM, and the current workspace is barely 300mb.
Is there any workaround to this? Anyone has any experience with this error?

Thanks,
-Jose
#
On 6/22/2007 1:26 PM, Jose Quesada wrote:
If tasa is sparse, then tasa+1 will not be sparse, so that's likely your 
problem.  You might have better luck with

log1p(tasa)

if the authors of the Matrix package have written a method for log1p(); 
if not, you'll probably have to do it yourself.

Duncan Murdoch
#
[Jose, if you call the Matrix *package* "library" once more, ...
 GRRRRR! ..]

        
DM> On 6/22/2007 1:26 PM, Jose Quesada wrote:
>> I have a pretty large sparse matrix of integers:
    >>> dim(tasa)
    >> [1] 91650 37651
    >> 
    >> I need to add one to it in order to take logs, but I'm
    >> getting the following error:
    >> 
    >>> tasa = log(tasa + 1)
    >> CHOLMOD error: problem too large Error in
    >> asMethod(object) : Cholmod error `problem too large'
    >> 
    >> I have 2 Gb of RAM, and the current workspace is barely
    >> 300mb.  Is there any workaround to this? Anyone has any
    >> experience with this error?
    >> 

    DM> If tasa is sparse, then tasa+1 will not be sparse, so
    DM> that's likely your problem.

[of course]

    DM> You might have better luck with

    DM> log1p(tasa)

{very good point, thank you, Duncan!}

    DM> if the authors of the Matrix package have written a
    DM> method for log1p(); if not, you'll probably have to do
    DM> it yourself.

They have not yet.

Note however that this - and expm1() - would automagically work
for sparse matrices if these two functions were part of the
"Math" S4 group generic.

I'd say that there's only historical reason for them *not* to be
part of "Math", and I am likely going to propose to change this
....

Martin Maechler

    DM> Duncan Murdoch