[Rd] Mismatches for methods registered for non-generic:
I’m trying to repair my SparseM package to meet new CRAN rules. The fun part
was rewriting the arithmetic-ifs in cholesky.f — to conform with new fortran
rules. (This struck me as a bit like updating “the wine dark seas” in Homer.)
Now, my remaining trouble is that I have several functions declared as
generic, e.g.
setGeneric("as.matrix.coo")
setMethod("as.matrix.coo","matrix.csr", function(x, nrow,
ncol,eps){.csr.coo(x)})
that have been fine until now and on my fresh R version 4.4.0 (2024-04-24) are
still ok with R CMD check —as-cran but CRAN checking reveals, e.g.
Check: S3 generic/method consistency, Result: NOTE
Mismatches for methods registered for non-generic:
as:
function(object, Class, strict, ext)
as.matrix.coo:
function(x, nrow, ncol, eps, …)
which I interpret as regarding my generics as just S3 methods for the
non-generic “as”. Can someone advise on the best way to repair this?
With best regards, and eternal gratitude for the efforts of R-core in making R
a living language.
Roger Koenker
r.koen...@ucl.ac.uk
Honorary Professor of Economics
Department of Economics, UCL
Emeritus Professor of Economics
and Statistics, UIUC
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Mismatches for methods registered for non-generic:
В Mon, 27 May 2024 10:52:26 +
"Koenker, Roger W" пишет:
> that have been fine until now and on my fresh R version 4.4.0
> (2024-04-24) are still ok with R CMD check —as-cran
This extra check requires the environment variable
_R_CHECK_S3_METHODS_SHOW_POSSIBLE_ISSUES_ to be set to TRUE to show the
issues.
> but CRAN checking reveals, e.g.
>
> Check: S3 generic/method consistency, Result: NOTE
> Mismatches for methods registered for non-generic:
> as:
>function(object, Class, strict, ext)
> as.matrix.coo:
>function(x, nrow, ncol, eps, …)
>
> which I interpret as regarding my generics as just S3 methods for
> the non-generic “as”.
There are calls to S3method("as", ...) and S3method("is", ...) at the
end of the NAMESPACE for the current CRAN version of SparseM. If I
comment them out, the package passes R CMD check --as-cran without the
NOTE and seemingly with no extra problems.
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Keep class attribute when applying c() to hexmodes
Dear list,
The following behavior in base R is unexpected to me:
a <- as.hexmode("99ac")
b <- as.hexmode("9ce5")
v <- c(a,b)
v
#> [1] 39340 40165
class(v)
#> [1] "integer"
Is there a good reason why v should not be of class "hexmode"?
I can see that this is exactly as documented. The help for `c()` only says that
the arguments are coerced to a common type (which is integer anyway) and that
all attributes except names are removed. On the other hand, it says further
down that "c methods other than the default are not required to remove
attributes (and they will almost certainly preserve a class attribute)".
So couldn't (or even shouldn't) there be a c.hexmode that keeps the class
attribute?
Best regards,
Dominic
--
Prof. Dr. Dominic Schuhmacher
Institute for Mathematical Stochastics
University of Göttingen, Germany
https://dschuhm1.pages.gwdg.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Keep class attribute when applying c() to hexmodes
On 2024-05-27 11:49 a.m., Schuhmacher, Dominic wrote:
Dear list,
The following behavior in base R is unexpected to me:
a <- as.hexmode("99ac")
b <- as.hexmode("9ce5")
v <- c(a,b)
v
#> [1] 39340 40165
class(v)
#> [1] "integer"
Is there a good reason why v should not be of class "hexmode"?
I can see that this is exactly as documented. The help for `c()` only says that the
arguments are coerced to a common type (which is integer anyway) and that all attributes
except names are removed. On the other hand, it says further down that "c methods
other than the default are not required to remove attributes (and they will almost
certainly preserve a class attribute)".
So couldn't (or even shouldn't) there be a c.hexmode that keeps the class
attribute?
I believe there could. If you think there should, then you should
submit a patch containing it to bugs.r-project.org. Based on c.Date,
here's a first attempt:
c.hexmode <- function(...) as.hexmode(c(unlist(lapply(list(...),
function(e) unclass(as.hexmode(e))
If you want this to be incorporated into R, you should test it, document
it, and submit a patch containing it.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
