Matrix / SparseM conflict (PR#8618)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Matrix / SparseM conflict (PR#8618)

D.Pleydell
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.

with gratitude
David


> library(Matrix)
> sm <- as(as(Matrix(diag(5) + 1), "dsyMatrix"), "dspMatrix")
> chol(sm)
5 x 5 Matrix of class "pCholesky"
     [,1]      [,2]      [,3]      [,4]      [,5]    
[1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
[2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
[3,]         .         . 1.1547005 0.2886751 0.2886751
[4,]         .         .         . 1.1180340 0.2236068
[5,]         .         .         .         . 1.0954451
>
> library(SparseM)
[1] "SparseM library loaded"
> chol(sm)
Error in chol(sm) : no applicable method for "chol"
>
> detach("package:SparseM")
> chol(sm)
5 x 5 Matrix of class "pCholesky"
     [,1]      [,2]      [,3]      [,4]      [,5]    
[1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
[2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
[3,]         .         . 1.1547005 0.2886751 0.2886751
[4,]         .         .         . 1.1180340 0.2236068
[5,]         .         .         .         . 1.0954451
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Matrix / SparseM conflict (PR#8618)

Duncan Murdoch
On 2/20/2006 8:54 AM, [hidden email] 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).

If you want access to the version in Matrix after attaching SparseM
ahead of it in the search path, use Matrix::chol.

 > library(Matrix)
 > sm <- as(as(Matrix(diag(5) + 1), "dsyMatrix"), "dspMatrix")
 > library(SparseM)
[1] "SparseM library loaded"
 > chol(sm)
Error in chol(sm) : no applicable method for "chol"
 > Matrix::chol(sm)
5 x 5 Matrix of class "pCholesky"
      [,1]      [,2]      [,3]      [,4]      [,5]
[1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
[2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
[3,]         .         . 1.1547005 0.2886751 0.2886751
[4,]         .         .         . 1.1180340 0.2236068
[5,]         .         .         .         . 1.0954451

You might want to discuss this with the SparseM package maintainers;
perhaps they don't really need to define their own generic.

Duncan Murdoch

>
> with gratitude
> David
>
>
>> library(Matrix)
>> sm <- as(as(Matrix(diag(5) + 1), "dsyMatrix"), "dspMatrix")
>> chol(sm)
> 5 x 5 Matrix of class "pCholesky"
>      [,1]      [,2]      [,3]      [,4]      [,5]    
> [1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
> [2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
> [3,]         .         . 1.1547005 0.2886751 0.2886751
> [4,]         .         .         . 1.1180340 0.2236068
> [5,]         .         .         .         . 1.0954451
>>
>> library(SparseM)
> [1] "SparseM library loaded"
>> chol(sm)
> Error in chol(sm) : no applicable method for "chol"
>>
>> detach("package:SparseM")
>> chol(sm)
> 5 x 5 Matrix of class "pCholesky"
>      [,1]      [,2]      [,3]      [,4]      [,5]    
> [1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
> [2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
> [3,]         .         . 1.1547005 0.2886751 0.2886751
> [4,]         .         .         . 1.1180340 0.2236068
> [5,]         .         .         .         . 1.0954451
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Matrix / SparseM conflict (PR#8618)

Brian Ripley
In reply to this post by D.Pleydell
Both are contributed packages. The R-bugs repository is for bugs in R, not
for contributed packages, as clearly stated in the R FAQ.

   Finally, check carefully whether the bug is with R, or a contributed
   package.  Bug reports on contributed packages should be sent first to
   the  package maintainer, and only submitted to the R-bugs repository by
   package maintainers, mentioning the package in the subject line.

Please contact the maintainers.  (It looks to me as if the problem is in
SparseM, so you could try loading it first.)

On Mon, 20 Feb 2006, [hidden email] 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.
>
> with gratitude
> David
>
>
>> library(Matrix)
>> sm <- as(as(Matrix(diag(5) + 1), "dsyMatrix"), "dspMatrix")
>> chol(sm)
> 5 x 5 Matrix of class "pCholesky"
>     [,1]      [,2]      [,3]      [,4]      [,5]
> [1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
> [2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
> [3,]         .         . 1.1547005 0.2886751 0.2886751
> [4,]         .         .         . 1.1180340 0.2236068
> [5,]         .         .         .         . 1.0954451
>>
>> library(SparseM)
> [1] "SparseM library loaded"
>> chol(sm)
> Error in chol(sm) : no applicable method for "chol"
>>
>> detach("package:SparseM")
>> chol(sm)
> 5 x 5 Matrix of class "pCholesky"
>     [,1]      [,2]      [,3]      [,4]      [,5]
> [1,] 1.4142136 0.7071068 0.7071068 0.7071068 0.7071068
> [2,]         . 1.2247449 0.4082483 0.4082483 0.4082483
> [3,]         .         . 1.1547005 0.2886751 0.2886751
> [4,]         .         .         . 1.1180340 0.2236068
> [5,]         .         .         .         . 1.0954451
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

--
Brian D. Ripley,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Matrix / SparseM conflict (PR#8618)

Brian Ripley
In reply to this post by Duncan Murdoch
On Mon, 20 Feb 2006, Duncan Murdoch wrote:

> On 2/20/2006 8:54 AM, [hidden email] 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.

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,                  [hidden email]
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Matrix / SparseM conflict (PR#8618)

RKoenker
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, [hidden email] 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,                  [hidden email]
> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel