similar to: R-devel Digest, Vol 167, Issue 25

Georgi, Brilliant, thank you very much for the helpful reply and explanation! I added 'importFrom("Matrix","as.matrix")' to my NAMESPACE and all worked fine! As my 'as.matrix' method is used entirely internally to the 'testmat' function (and not "used outside the package"), I don't think I actually need to export it. In my case, testmat is

CRAN reached 12,000 packages [1] today (December 15, 2017). A huge thank you to the CRAN team! Milestones: 2017-12-15 12000 pkgs (+6.1/day over 165 days) 6910 mnts (+3.2/day) 2017-07-04 11000 pkgs (+6.3/day over 159 days) 6377 mnts (+3.3/day) 2017-01-27 10000 pkgs (+6.3/day over 158 days) 5845 mnts (+3.5/day) 2016-08-22 9000 pkgs (+5.7/day over 175 days) 5289 mnts (+5.8/day) 2016-02-29 8000

Continuing the tradition to post millennia milestones on CRAN: So, it happened. Today (January 27, 2017 PCT) CRAN reached 10,000 packages [1]. Needless to say, the rate with which new packages are added to CRAN keeps increasing and so does the number of contributors (maintainers). Somewhere out there, there are ~3 persons who are about to submit their first packages to CRAN today and ~3 persons

Hi, The Matrix package and the as.matrix method do not seem to be compatible inside of a package. Here's an example. I've created a simple package "mat" that defines an eponymous class and as.matrix method on that class. All is well, unless that package has the Matrix package in its Depends or Imports (and imports, e.g. the "Diagonal" function). Then my as.matrix

Hi, I am not sure to get the issue, but assuming your data are arranged as in your example with dates in column x$V1 and signals as x$V2 , I think that you could use "rle" in the following way : test<-rle(x$V2) testmat<-matrix(NA,length(test$values),2) testmat[,1]<-x[c(1,cumsum(test$length)[1:(length(test$values)-1)]+1),1] testmat[,2]<-test$values And you'll get your

With rw2010dev I get a strange protect(): protection stack overflow error with a small data frame which otherwise is usable: If anybody wants to have a look I can provide an RData file with the problematic data frame. Doesn't seem to be necessary, the following simulated example generates the error: > testmat <- matrix(1:80, 20,4) > dim(testmat) [1] 20 4 > str(testmat) int

Hello All, I'm trying to run a maximum likelihood analysis using dmultinomial (i'm avoiding dmultinom as I'd like to run it with vectors for the ML stuff). However, I'm having a hard time getting even the simplest example running. Any help would be greatly appreciated. > library(mc2d) > dmultinomial(x=c(0,0,1),prob=c(1,1,1),size=1,log=TRUE) Error in if (ncol(x) != K)

I'm trying to update my Matrix package given the update last night. But the following error is generated. I've tried restarting R and deleting my old Matrix package. Can anyone suggest how this might be resolved? > install.packages('Matrix') trying URL 'http://www.ibiblio.org/pub/languages/R/CRAN/bin/windows/contrib/2.1/Mat rix_0.98-1.zip' Content type

First off, I don't know if this is password caching revisited with a vengeance or what. It's very inconsistent for the amount of time the share will stay mounted. I *think* the following are the relevant messagess in the log: Jun 23 22:24:36 reliant kernel: smb_trans2_request: result=-32, setting invalid Jun 23 22:24:36 reliant kernel: smb_retry: caught signal And of course, I get the

Hi, I'm hoping to get some clarification of the intent of some of directives used in NAMESPACE files. 1. Is import(somePkg) also intended to import all classes and methods that are exported via exportClasses and exportMethods in somePkg? I think import pulls in classes and methods, but it isn't clear from the docs whether this is as intended. 2. What is exportMethods intended

We are building a package, and want to create S4 methods for both head and mean for our own BigMatrix class. Following the recommendation in "Writing R Extensions" we use exportMethods instead of export in NAMESPACE (this is described as being "clearer"). This works for head, but not for mean. Obviously we importFrom(utils, head), but don't need to do this for mean,

Defending the status quo misses the point that R *could* handle ordinal data with a fixed set of levels but actually *does not*. Although it would be useful. Even if this does not imply to handle any possible straw-man situations. Having data-types for nominal, ordinal, and interval-scale data is - in theory - one of the major advantages of S over SAS. But *having* without *handling* means: only

Dear List: I am estimating a gls model and am having to make some rather unconventional modifications to handle a particular problem I have identified. My aim is to fit a GLS with an AR1 structure, obtain the variance-covariance matrix (V), modify it as needed given my research problem, and then reestimate the GLS by brute force using matrix operations. All seems to be working almost perfectly,

The current version of the methods package now has a namespace. Packages using S4 methods and classes can have NAMESPACE files. New directives can be included in NAMESPACE files to import and export classes and methods. Namespaces allow cleaner definition of the API for packages, and are needed for future improvements to R. NOTE: This is a major revision. In principle, it should be back

> R.version.string [1] "R Under development (unstable) (2012-02-26 r58493)" In the recent addition "It is important if you export S4 methods that the corresponding generics are available: the requirementa on this are stricter as from R 2.15.0. You may for example need to import plot from graphics to make visible a function to be converted into its implicit generic. But it is

In > R.version.string [1] "R Under development (unstable) (2011-12-15 r57901)" section 1.6.6 of 'Writing R Extensions' says Note that exporting methods on a generic in the namespace will also export the generic, and exporting a generic in the namespace will also export its methods. and Note that importMethodsFrom will also import any generics defined in

I'm working with an historical image that may be (one of?) the first uses of gray-scale shading to show the pattern of values in a matrix/table, later used by Bertin in his 'reorderable matrix' and sometimes called a scalogram. The image is at http://euclid.psych.yorku.ca/SCS/Gallery/images/Private/scalogram.jpg The rows refer to the arrondisements of Paris, the cols to various

Late to the show on this release, unfortunately. One of our production packages no longer builds under R-2.15.0 with the following message. ** testing if installed package can be loaded Error: Function found when exporting methods from the namespace 'SuperCurve' which is not S4 generic: 'image' Possibly relevant clues follow: ## From R/AllGenerics.R if

I have a question about what to do in the following situation (please bear with the setup): Package A defines an S4 generic 'foo' and as well as S4 methods for 'foo' and has exportMethods("foo") in its NAMESPACE file. Package B defines another method for 'foo' for class "bar" and has importFrom(A, "foo") exportMethods("foo")

Hi everyone, -r136747 of llvm-gcc (and possibly others) is apparently tickling a binutils issue on linux x86-64 Has anyone seen anything like this? Thanks -jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110806/e7e717ef/attachment.html> -------------- next part --------------