Re: [Rd] namespace S3 and S4 generic imports cannot both be satisfied:
On 12/09/2012 08:27 PM, John Chambers wrote:
Yes, you are right.
Mixing S3 and S4 methods for a generic is fine, although in subtle cases one is
safer promoting the S3 method to an S4 method, as you did in your example.
Usually, the default method for the S4 generic is the S3 generic. But, in
general, it's not possible to check algorithmically whether the S3 methods will
be dispatched. For example, an S4 method on "vector" could dispatch S3 methods
on subclasses "numeric", etc. (don't ask why ...), for a generic that had no
default method.
That the trouble with this check isn't found right away is likely because one is
typically working with a primitive where no generic function is created.
Should be fixed in rev. 61263. Please check on your real example; it seems fine
on the test you submitted.
Thanks, this addresses the problem for our real example. Martin
Thanks for the catch.
John
On 12/8/12 3:05 PM, Martin Morgan wrote:
PkgA wishes to write a method for 'unique' on S4 class 'A'. ?Methods
indicates that one should
setGeneric("unique")
setClass("A")
unique.A <- function(x, incomparables=FALSE, ...) {}
setMethod(unique, "A", unique.A)
Both S3 and S4 methods need to be exported in the NAMESPACE
import(methods)
S3method(unique, A)
exportMethods(unique)
PkgB introduces a new class and method
setClass("B")
unique.B <- function(x, incomparables=FALSE, ...) {}
setMethod(unique, "B", unique.B)
and in the NAMESPACE has
import(methods)
importFrom(PkgA, unique)
S3method(unique, B)
exportMethods(unique)
Unfortuantely, R CMD check says that
* checking whether package 'PkgB' can be installed ... WARNING
Found the following significant warnings:
Warning: found an S4 version of 'unique' so it has not been imported
correctly
See '/home/mtmorgan/tmp/PkgB.Rcheck/00install.out' for details.
This is from (svn r61253) R-devel/src/library/base/R/namespace.R:1339,
where the code finds the S4 generic, but not the S3 generic. Obviously
the namespace cannot have both the S3 and S4 symbols defined, but this
seems to be required? A workaround might extend the check to include
getGeneric(genname)@default.
This scenario is reproducible in the attached tarball
tar xzf PkgAB.tar.gz
R CMD INSTALL PkgA
R CMD check PkgB
Martin Morgan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Strange, most probably unjustified, codoc mismatch for S4 method with one argument plus '...' (re-try)
Hi,
I just figured out that I accidentally posted my message in HTML, so I
am retrying in plain text only. Sorry.
I am currently extending one of our CRAN packages and ran into an
unexpected problem when checking the source package. I got some warnings
in the step "* checking for code/documentation mismatches". I double
checked everything and did not see anything that would actually justify
this warning. After testing around for quite a while, I think I can now
pinpoint the problem. In order to make myself clear, I need to explain
the situation in more detail:
The default method (passed as def argument of setGeneric()) has the
formal argument list (x, y, ...). Suppose I want to register a method
with a signature without y, say signature(x="matrix", y="missing"). If I
pass a function to setMethod() that only has the argument x,i.e.
function(x) {...}, everything works well. It also works well if I
register a function with additional arguments, e.g. function(x,
dummy=NULL, ...){...} (note: y is missing in the definition). However,
if I try to register a function with two formal arguments, x and '...',
i.e.function(x, ...){...}, I get the warning that argument y is present
in the code but missing in the documentation , although it is actually
NOT in the code. In order to make this reproducible for everybody, I put
together a little dummy package in which one of the methods leads to
exactly this warning:
http://www.bioinf.jku.at/people/bodenhofer/codocMismatchTest_0.0.1.tar.gz
Just run 'R CMD check' on this archive and you'll see. You will also see
from the code and the corresponding documentation that the warning seems
unjustified. I tried the following R versions: 2.12.1, 2.13.0, 2.13.1,
2.14.0, 2.14.1, 2.15.0, 2.15.1, 2.15.2, 2.16.0 (devel), and all
consistently gave the same warning.
Is this a bug or is there a special reason for this behavior? Any help
is gratefully appreciated!
Thanks in advance and best regards,
Ulrich
*Dr. Ulrich Bodenhofer*
Associate Professor
Institute of Bioinformatics
*Johannes Kepler University*
Altenberger Str. 69
4040 Linz, Austria
Tel. +43 732 2468 4526
Fax +43 732 2468 4539
bodenho...@bioinf.jku.at
http://www.bioinf.jku.at/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?
> "PJ" == Paul Johnson > on Fri, 14 Dec 2012 01:01:19 -0600 writes: PJ> On Thu, Dec 13, 2012 at 9:01 PM, Yi (Alice) Wang wrote: >> I have also encountered a similar problem. My mvabund package runs much >> faster on linux/OSX than on windows with both R/2.15.1 and R/2.15.2. For >> example, with mvabund_3.6.3 and R/2.15.2, >> system.time(example(anova.manyglm)) >> PJ> Hi, Alice PJ> You have a different problem than I do. PJ> The change from R-2.15.1 to R-2.15.2 makes the program slower on all PJ> platforms. The slowdown that emerges in R-2.15.2 on all types of PJ> hardware concerns me. PJ> It only seemed like a "Windows is better" issue when all the Windows PJ> users who tested my program were using R-2.15.0 or R-2.15.1. As soon PJ> as they update R, then they have the slowdown as well. Paul, I'm pretty sure you are right that it is not just your package. Rather, the NEWS for R 2.15.2 contain • The included LAPACK has been updated to 3.4.1, with some patches from the current SVN sources. (_Inter alia_, this resolves PR#14692.) and as I got from your e-mails --- yes, a reproducible example (without package Amelia) would have been (and would still be) really enlightening --- indeed, "the default tolerance" (in a vague sense) of detecting (near)singularity may well have been tightened in the newer LAPACK. Martin >> on OSX returns >> >> user system elapsed >> 3.351 0.006 3.381 >> >> but on windows 7 it returns >> >> user system elapsed >> 13.13 0.00 13.14 >> >> I also used svd frequently in my c code though by calling the gsl functions >> only. In my memory, I think the comp time difference is not that significant >> with earlier R versions. So maybe it is worth an investigation? >> >> Many thanks, >> Yi Wang >> >> >> On Thu, Dec 13, 2012 at 5:33 PM, Uwe Ligges >> wrote: >>> >>> Long message, but as far as I can see, this is not about base R but the >>> contributed package Amelia: Please discuss possible improvements with its >>> maintainer. >>> >>> Best, >>> Uwe Ligges >>> >>> >>> On 12.12.2012 19:14, Paul Johnson wrote: Speaking of optimization and speeding up R calculations... I mentioned last week I want to speed up calculation of generalized inverses. On Debian Wheezy with R-2.15.2, I see a huge speedup using a souped up generalized inverse algorithm published by V. N. Katsikis, D. Pappas, Fast computing of theMoore-Penrose inverse matrix, Electronic Journal of Linear Algebra, 17(2008), 637-650. I was so delighted to see the computation time drop on my Debian system that I boasted to the WIndows users and gave them a test case. They answered back "there's no benefits, plus Windows is faster than Linux". That sent me off on a bit of a goose chase, but I think I'm beginning to understand the situation. I believe R-2.15.2 introduced a tighter requirement for precision, thus triggering longer-lasting calculations in many example scripts. Better algorithms can avoid some of that slowdown, as you see in this test case. Here is the test code you can run to see: http://pj.freefaculty.org/scraps/profile/prof-puzzle-1.R It downloads a data file from that same directory and then runs some multiple imputations with the Amelia package. Here's the output from my computer http://pj.freefaculty.org/scraps/profile/prof-puzzle-1.Rout That includes the profile of the calculations that depend on the ordinary generalized inverse algorithm based on svd and the new one. See? The KP algorithm is faster. And just as accurate as Amelia:::mpinv or MASS::ginv (for details on that, please review my notes in http://pj.freefaculty.org/scraps/profile/qrginv.R). So I asked WIndows users for more detailed feedback, including sessionInfo(), and I noticed that my proposed algorithm is not faster on Windows--WITH OLD R! Here's the script output with R-2.15.0, shows no speedup from the KPginv algorithm http://pj.freefaculty.org/scraps/profile/prof-puzzle-1-Windows.Rout On the same machine, I updated to R-2.15.2, and we see the same speedup from the KPginv algorithm http://pj.freefaculty.org/scraps/profile/prof-puzzle-1-CRMDA02-WinR2.15.2.Rout After that, I realized it is an R version change, not an OS difference, I was a bit relieved. What causes the diff
Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?
On 14.12.2012 07:55, Paul Johnson wrote: On Thu, Dec 13, 2012 at 3:33 AM, Uwe Ligges wrote: Long message, but as far as I can see, this is not about base R but the contributed package Amelia: Please discuss possible improvements with its maintainer. Thanks for answering, but I'm really surprised by your answer. The package is a constant, but R got much slower between R-2.15.1 and R-2.15.2. The profile of functions called radically changed, svd gets called much more because solve() fails much more often. I have screened your mail and I have seen statements and code re. Amelia. If you are talking about R, please provide reproducible examples without overhead of packages. The CRAN check times of > 4000 packages are typically a good indicator, and they are a bit slower for R-2.15.2 but not that it is generally worrying (since we also run more checks). No change in R could account for it? I'm not saying R is wrong, it may be more accurate and better. After chasing the slowdown for a week, I need some comfort. Does the LINPACK -> LAPACK change play a role. The change I'm looking for is something that would substantially tune up mathematical precision so that matrices that did not seem singular before are now, in the eyes of functions like chol() and solve(). Whereas in R-2.15.1, a matrix can be inverted by solve(), for example, now R-2.15.2 rejects the matrix as singular. Then a LAPACK upgrade for bugfix reasons, I believe. I will take the problem up with applications, of course. But you see how package writers might think its ridiculous. They argue, "I had a perfectly fine calculation against R-2.15.0 and R-2.15.1, and now with R-2.15.2 it takes three times as long? And you want me to revise my package?" Would you be persuaded there's an R base question if I showed you a particular matrix that can be decomposed or solved in R-2.15.1 but cannot be in R-2.15.2? I should have thought of that before, I suppose :) Yes, a minimal reproducible example would be good, but then it is probably a LAPACK issue and we have to convince the LAPACK people to improve code. Best, uwe pj Best, Uwe Ligges On 12.12.2012 19:14, Paul Johnson wrote: Speaking of optimization and speeding up R calculations... I mentioned last week I want to speed up calculation of generalized inverses. On Debian Wheezy with R-2.15.2, I see a huge speedup using a souped up generalized inverse algorithm published by V. N. Katsikis, D. Pappas, Fast computing of theMoore-Penrose inverse matrix, Electronic Journal of Linear Algebra, 17(2008), 637-650. I was so delighted to see the computation time drop on my Debian system that I boasted to the WIndows users and gave them a test case. They answered back "there's no benefits, plus Windows is faster than Linux". That sent me off on a bit of a goose chase, but I think I'm beginning to understand the situation. I believe R-2.15.2 introduced a tighter requirement for precision, thus triggering longer-lasting calculations in many example scripts. Better algorithms can avoid some of that slowdown, as you see in this test case. Here is the test code you can run to see: http://pj.freefaculty.org/scraps/profile/prof-puzzle-1.R It downloads a data file from that same directory and then runs some multiple imputations with the Amelia package. Here's the output from my computer http://pj.freefaculty.org/scraps/profile/prof-puzzle-1.Rout That includes the profile of the calculations that depend on the ordinary generalized inverse algorithm based on svd and the new one. See? The KP algorithm is faster. And just as accurate as Amelia:::mpinv or MASS::ginv (for details on that, please review my notes in http://pj.freefaculty.org/scraps/profile/qrginv.R). So I asked WIndows users for more detailed feedback, including sessionInfo(), and I noticed that my proposed algorithm is not faster on Windows--WITH OLD R! Here's the script output with R-2.15.0, shows no speedup from the KPginv algorithm http://pj.freefaculty.org/scraps/profile/prof-puzzle-1-Windows.Rout On the same machine, I updated to R-2.15.2, and we see the same speedup from the KPginv algorithm http://pj.freefaculty.org/scraps/profile/prof-puzzle-1-CRMDA02-WinR2.15.2.Rout After that, I realized it is an R version change, not an OS difference, I was a bit relieved. What causes the difference in this case? In the Amelia code, they try to avoid doing the generalized inverse by using the ordinary solve(), and if that fails, then they do the generalized inverse. In R 2.15.0, the near singularity of the matrix is ignored, but not in R 2.15.2. The ordinary solve is failing almost all the time, thus triggering the use of the svd based generalized inverse. Which is slower. The Katsikis and Pappas 2008 algorithm is the fastest one I've found after translating from Matlab to R. It is not so universally applicable as svd based methods, it will fail if there are linearly dependent columns. However, it does tol
Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?
On 14 December 2012 at 18:07, Uwe Ligges wrote: | without overhead of packages. The CRAN check times of > 4000 packages | are typically a good indicator, and they are a bit slower for R-2.15.2 And sadly less so when you force us to turn tests off. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?
On 14.12.2012 18:11, Dirk Eddelbuettel wrote: On 14 December 2012 at 18:07, Uwe Ligges wrote: | without overhead of packages. The CRAN check times of > 4000 packages | are typically a good indicator, and they are a bit slower for R-2.15.2 Please do not quote only parts of my sentences, that one was continued: "but not that it is generally worrying (since we also run more checks)." Thanks, Uwe And sadly less so when you force us to turn tests off. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small issue with over-zealous clean.
On 14.12.2012 04:15, Hin-Tak Leung wrote: --- On Sun, 9/12/12, Dirk Eddelbuettel wrote: Do you REALLY think svn would not know about missing files? There does not seem to be a limit on the disdain for svn among git users. Fascinating. FWIW, as one of the linux kernel maintainers, I don't apologize for being familiar with git. I did not decide git as the official tool for maintaining the linux kernel. Linus did. There does not seem to be a limit on the disdain for the linux kernel among debian users. Fascinating. There *is* no limit on the disdain for people discussing off-topic svn/git/linux disdains on the *R*-devel list among R developers. Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?
On 14 December 2012 at 18:19, Uwe Ligges wrote: | | | On 14.12.2012 18:11, Dirk Eddelbuettel wrote: | > | > On 14 December 2012 at 18:07, Uwe Ligges wrote: | > | without overhead of packages. The CRAN check times of > 4000 packages | > | are typically a good indicator, and they are a bit slower for R-2.15.2 | | Please do not quote only parts of my sentences, that one was continued: | | "but not that it is generally worrying (since we also run more checks)." I understand the resource constraint, but the fact remains that on the CRAN side most-visible package I am involved with now runs _way fewer_ tests than it used to, making these very comparisons across time a little tricky. Rock, meet hard place. In an ideal world we had way more tests, and comparisons among them. But time is, alas, finite... Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.15.2 changes in computation speed. Numerical precision?
On 12/14/2012 9:32 AM, Dirk Eddelbuettel wrote:
On 14 December 2012 at 18:19, Uwe Ligges wrote:
|
|
| On 14.12.2012 18:11, Dirk Eddelbuettel wrote:
| >
| > On 14 December 2012 at 18:07, Uwe Ligges wrote:
| > | without overhead of packages. The CRAN check times of > 4000 packages
| > | are typically a good indicator, and they are a bit slower for R-2.15.2
|
| Please do not quote only parts of my sentences, that one was continued:
|
| "but not that it is generally worrying (since we also run more checks)."
I understand the resource constraint, but the fact remains that on the CRAN
side most-visible package I am involved with now runs _way fewer_ tests than
it used to, making these very comparisons across time a little tricky.
Rock, meet hard place. In an ideal world we had way more tests, and
comparisons among them. But time is, alas, finite...
This raises again the question of why the CRAN resources are so
constrained?
I don't know the answer to that, but I assume it's because the
current CRAN maintainers would rather force package maintainers to turn
off tests than recruit help to fix the resource constraints in other
ways. I just fit a log-logistic model using drm{drc} to the number of
CRAN packages using data from John Fox (2009) "Aspects of the Social
Organization and Trajectory of the R Project", R Journal
(http://journal.r-project.org/archive/2009-2/RJournal_2009-2_Fox.pdf),
with some points I added with more recent data.
From this model fit, I estimate the doubling time for the number
of CRAN packages at roughly 4.5 years. This is triple the historic 18
month speed improvements achieved since 1971 and is still 1.5 times the
3 year doubling time for number of transistors per chip forecasted by
the 2010 update to the International Technology Roadmap for
Semiconductors (Wikipedia, "Moore's Law"). From this, I infer that a
reasonable replacement schedule for hardware in the current CRAN server
farm should be able to solve this problem and release this constraint on
CRAN test time.
Jim Ramsay suggested that if money is a constraint, he has grant
money that could pay some nominal fee for CRAN usage provided he could
get an invoice. CRAN could still be free for anyone without the ability
to easily pay such, like page charges in many journal. However, his
grant money can NOT be used to make contributions.
A "CRAN" function has been added to the "fda" package to test to
see if it was running "--as-cran"; we use this to skip tests if TRUE.
Ramsay and I are with Dirk: We wish there were a way to release this
compute time constraint on CRAN. However, we have so far been unable to
get information on the source of that constraint. (R-Forge is similarly
a very valuable service with other known problems, also with unknown
causes.)
Best Wishes,
Spencer
Dirk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small issue with over-zealous clean.
--- On Fri, 14/12/12, Uwe Ligges wrote: > On 14.12.2012 04:15, Hin-Tak Leung wrote: > > --- On Sun, 9/12/12, Dirk Eddelbuettel > wrote: > > > > > >> Do you REALLY think svn would not know about > missing > >> files? There does not > >> seem to be a limit on the disdain for svn among git > users. > >> Fascinating. > > > > FWIW, as one of the linux kernel maintainers, I don't > apologize for being familiar with git. I did not decide git > as the official tool for maintaining the linux kernel. Linus > did. > > > > There does not seem to be a limit on the disdain for > the linux kernel among debian users. > > Fascinating. > > > There *is* no limit on the disdain for people discussing > off-topic > svn/git/linux disdains on the *R*-devel list among R > developers. That needs a "Fascinating" exclamation at the end to be genuine and authentic for the typical R developers/debian users. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small issue with over-zealous clean.
On Dec 14, 2012, at 1:48 PM, Hin-Tak Leung wrote: > --- On Fri, 14/12/12, Uwe Ligges wrote: > >> On 14.12.2012 04:15, Hin-Tak Leung wrote: >>> --- On Sun, 9/12/12, Dirk Eddelbuettel >> wrote: >>> >>> Do you REALLY think svn would not know about >> missing files? There does not seem to be a limit on the disdain for svn among git >> users. Fascinating. >>> >>> FWIW, as one of the linux kernel maintainers, I don't >> apologize for being familiar with git. I did not decide git >> as the official tool for maintaining the linux kernel. Linus >> did. >>> >>> There does not seem to be a limit on the disdain for >> the linux kernel among debian users. >>> Fascinating. >> >> >> There *is* no limit on the disdain for people discussing >> off-topic >> svn/git/linux disdains on the *R*-devel list among R >> developers. > > That needs a "Fascinating" exclamation at the end to be genuine and authentic > for the typical R developers/debian users. That's enough of this off-topic subject matter. Take it off list if you wish to continue this dialog. Any further posts to R-Devel in this vain will not be tolerated. Marc Schwartz R-Devel Co-Admin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Found explanation for R-2.15.2 slowdown in one case; caution for any users of La_chol
2 days ago, I posted my long message about the observed slowdown in a package between R-2.15.0 and R-2.15.2. Uwe Ligges urged me to make a self-contained R example. That was the encouragement I needed. I tracked the problem down to a failing use of a LAPACK routine. R's LAPACK C interface changed one variable in one function. But it turned out to be an important change. In case others have code that is behaving in unexpected says, I'd urge package writers to double-check their usage of the Cholesky inverse. Here are details: In R 2.15.0, src/main/lapack.c, we have the prototype: SEXP La_chol (SEXP A) BUT in R 2.15.2, the prototype changed: SEXP La_chol (SEXP A, SEXP pivot) In the problem case I was studying, the effort to use La_chol was wrapped in a "try" catch framework, and when Cholesky failed, it fell back to a singular value decomposition. That's much slower, of course. Hence the program seemed slower under R-2.15.2, but it was really failing in a way that I had not noticed. pj -- Paul E. Johnson Professor, Political Science Assoc. Director 1541 Lilac Lane, Room 504 Center for Research Methods University of Kansas University of Kansas http://pj.freefaculty.org http://quant.ku.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange, most probably unjustified, codoc mismatch for S4 method with one argument plus '...' (re-try)
On 12/14/2012 09:46 AM, Ulrich Bodenhofer wrote:
Hi,
I just figured out that I accidentally posted my message in HTML, so I am
retrying in plain text only. Sorry.
I am currently extending one of our CRAN packages and ran into an unexpected
problem when checking the source package. I got some warnings in the step "*
checking for code/documentation mismatches". I double checked everything and did
not see anything that would actually justify this warning. After testing around
for quite a while, I think I can now pinpoint the problem. In order to make
myself clear, I need to explain the situation in more detail:
The default method (passed as def argument of setGeneric()) has the formal
argument list (x, y, ...). Suppose I want to register a method with a signature
without y, say signature(x="matrix", y="missing"). If I pass a function to
setMethod() that only has the argument x,i.e. function(x) {...}, everything
works well. It also works well if I register a function with additional
arguments, e.g. function(x, dummy=NULL, ...){...} (note: y is missing in the
definition). However, if I try to register a function with two formal arguments,
x and '...', i.e.function(x, ...){...}, I get the warning that argument y is
present in the code but missing in the documentation , although it is actually
NOT in the code. In order to make this reproducible for everybody, I put
together a little dummy package in which one of the methods leads to exactly
this warning:
http://www.bioinf.jku.at/people/bodenhofer/codocMismatchTest_0.0.1.tar.gz
Just run 'R CMD check' on this archive and you'll see. You will also see from
the code and the corresponding documentation that the warning seems unjustified.
I tried the following R versions: 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.14.1,
2.15.0, 2.15.1, 2.15.2, 2.16.0 (devel), and all consistently gave the same
warning.
Is this a bug or is there a special reason for this behavior? Any help is
gratefully appreciated!
In ?setMethod there is this paragraph
It is possible to have some differences between the formal
arguments to a method supplied to 'setMethod' and those of the
generic. Roughly, if the generic has ... as one of its arguments,
then the method may have extra formal arguments, which will be
matched from the arguments matching ... in the call to 'f'. (What
and in practice the expectation is that if a generic has formals x, y, and ...,
then a method will have formals x, y, and possibly additional arguments. None of
these methods follow this
setMethod("dummyMethod", signature(x="matrix", y="missing"),
function(x) {})
setMethod("dummyMethod", signature(x="matrix", y="missing"),
function(x) {})
setMethod("dummyMethod", signature(x="data.frame", y="missing"),
function(x, ...) {})
each should have been written as, for instance
setMethod("dummyMethod", signature(x="matrix", y="missing"),
function(x, y, ...) {})
The reason for the codoc warning stems from how R represents methods with
signatures different from their generic, typically when _additional_ arguments
are used,
(what
actually happens is that a local function is created inside the
method, with the modified formal arguments, and the method is
re-defined to call that local function.)
So e.g.,
selectMethod(dummyMethod, c("matrix", "missing"))
Method Definition:
function (x, y, ...)
{
.local <- function (x)
{
}
.local(x, ...)
}
Signatures:
xy
target "matrix" "missing"
defined "matrix" "missing"
and hence the codoc warning
* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'dummyMethod':
\S4method{dummyMethod}{data.frame,missing}
Code: function(x, y, ...)
Docs: function(x, ...)
Argument names in code not in docs:
y
Mismatches in argument names:
Position: 2 Code: y Docs: ...
Your other setMethod
also results in code that likely differs from your expectation, e.g., no
argument matching by position
setMethod("dummyMethod", signature(x="list", y="missing"),
function(x, sel=NULL, ...) {})
> selectMethod(dummyMethod, signature(x="list", y="missing"))
Method Definition:
function (x, y, ...)
{
.local <- function (x, sel = NULL, ...)
{
}
.local(x, ...)
}
Signatures:
x y
target "list" "missing"
defined "list" "missing"
Hope that helps,
Martin
>
Thanks in advance and best regards,
Ulrich
*Dr. Ulrich Bodenhofer*
Associate Professor
Institute of Bioinformatics
*Johannes Kepler University*
Altenberger Str. 69
4040 Linz, Austria
Tel. +43 732 2468 4526
Fax +43 732 2468 4539
bodenho...@bioinf.jku.at
http://www.bioinf.jku.at/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/l
