Skip to content

solve.Matrix() not found (PR#4887)

3 messages · Stefano Conti, Brian Ripley, Douglas Bates

#
# Your mailer is set to "none" (default on Windows),
# hence we cannot send the bug report directly from R.
# Please copy the bug report (after finishing it) to
# your favorite email program and send it to
#
#       r-bugs@r-project.org
#
######################################################



Dear R developers,

this  morning  I  started  experiencing  a  bizarre  problem  with the
solve.Matrix()  command  in  the  Matrix library: basically R does not
recognise such command any longer, no mettar if re-installation of the
library  is  done.  Any  insight  from  youwill be highly appreciated;
thanks in advance, best regards,

Stefano Conti



--please do not edit the information below--

Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = 
 major = 1
 minor = 8.0
 year = 2003
 month = 10
 day = 08
 language = R

Windows 2000 Professional (build 2195) Service Pack 4.0

Search Path:
 .GlobalEnv, package:Matrix, package:methods, package:ctest, package:mva, package:modreg, package:nls, package:ts, Autoloads, package:base
#
In what sense is this a bug?  *Please* read the description of BUGS in the 
FAQ.

Note:
function (a, b, tol = 0, transpose = FALSE, ...)
{
    if (missing(b))
        return(.Call("R_LapackPP_solve", a, NULL, PACKAGE = "Matrix"))
    .Call("R_LapackPP_solve", a, b, PACKAGE = "Matrix")
}
<environment: namespace:Matrix>

It's a *method* and is meant only to be called via the generic solve().
On Fri, 31 Oct 2003 s.conti@sheffield.ac.uk wrote:

            

  
    
#
To elaborate a bit - the reason that the behavior of the Matrix
package changed is because I uploaded a new version that has a
NAMESPACE file.  One result, as Brian Ripley points out, is that
direct calls to method functions, such as

 solve.Matrix(foo, bar)

that previously were acceptable now result in errors.  This call would
only produce a useful result if inherits(foo, "Matrix") is TRUE, in
which case it is equivalent to

 solve(foo, bar)

(unless another method for "solve" would take precedence).  This
version continues to work as expected - at least I hope so.

The moral of the story is that you should call the generic function,
not the method function.

This change is the first stage in a major rewrite of the Matrix
package that will include 

 - a switch from the underlying lapack++ code, which is
   no longer under active development, to C code such as cblas and
   clapack and, perhaps, FLAME 
                 http://www.cs.utexas.edu/users/flame

 - switch to S4 classes and methods

 - addition of sparse matrix methods based on TAUCS, UMFPACK, AMD,
   and, perhaps, METIS

 - moving the pdMat classes from the lme4 package to the Matrix
   package which I think is a more natural place for them.

Stay tuned.

Prof Brian Ripley <ripley@stats.ox.ac.uk> writes: