From rkoenker at uiuc.edu  Mon Feb 20 16:45:22 2006
From: rkoenker at uiuc.edu (roger koenker)
Date: Mon, 20 Feb 2006 09:45:22 -0600
Subject: [Rd] Matrix / SparseM conflict (PR#8618)
In-Reply-To: <Pine.LNX.4.64.0602201409480.28459@gannet.stats.ox.ac.uk>
References: <20060220135453.F08793F201@slim.kubism.ku.dk>
	<43F9CCB8.9030808@stats.uwo.ca>
	<Pine.LNX.4.64.0602201409480.28459@gannet.stats.ox.ac.uk>
Message-ID: <2EECC209-3A37-44E7-9518-69CAFD48D6CC@uiuc.edu>

On Feb 20, 2006, at 8:29 AM, Prof Brian Ripley wrote:

> On Mon, 20 Feb 2006, Duncan Murdoch wrote:
>
>> On 2/20/2006 8:54 AM, dpleydel at univ-fcomte.fr wrote:
>>> Full_Name: David Pleydell
>>> Version: 2.2.1
>>> OS: Debian Etch
>>> Submission from: (NULL) (193.55.70.206)
>>>
>>>
>>> There appears to be a conflict between the chol functions from  
>>> the Matrix and
>>> the SparseM packages. chol() can only be applied to a matrix of  
>>> class dspMatrix
>>> if SparseM is not in the path.
>>
>> This isn't a bug, it's simply that both Matrix and SparseM define a
>> generic for chol (though Matrix actually gets it by converting the
>> function in base).
>
> The problem appears to be that SparseM first redefines chol as an  
> S3 generic and then defines S4 methods on it.  As no new S3 methods  
> are then defined the S3 step would seem unnecessary, but it is used  
> to allow the package to define S4 methods on a different signature  
> from R's chol().
> (That seems to me to be asking for trouble.)
>
> Only the package maintainer of SparseM can do anything about this.

I'm happy to modify this, but would welcome advice.  The current  
snafu is a consequence of writing a first
version of SparseM with S3 methods and then converting (evidently  
incompletely) to S4.
>
> Beyond, that I guess it is a consequence of namespaces that Matrix  
> defines methods via a derived generic on base::chol and not on the  
> generic chol in SparseM.  That needs further thought by someone  
> (JMC?) who understands the S4 internals.
>
>> If you want access to the version in Matrix after attaching SparseM
>> ahead of it in the search path, use Matrix::chol.
>
> But the whole point of generic functions is to allow one to write  
> generic code.
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Matrix / SparseM conflict (PR#8618)
roger koenker