Error: "could not find function "lengths" - r

While running:
reg_model = glmer(modeling1 ~ pTOT_VIOPT_CT + (1|STUDY_CODE_ALIAS),
data=data_CACZ, family=binomial)
I am getting the error:
Error in .fixupDimnames(.Object#Dimnames) :
could not find function "lengths"
Not sure what could be the possible reason.
FYI: I am putting below the sessionInfo():
R version 3.0.2 (2013-09-25)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Rcpp_0.11.5 lme4_1.1-10 Matrix_1.2-3 car_2.0-21 MASS_7.3-29
loaded via a namespace (and not attached):
[1] grid_3.0.2 lattice_0.20-29 minqa_1.2.4 nlme_3.1-118 nloptr_1.0.4 nnet_7.3-7 splines_3.0.2 tools_3.0.2

(From the maintainer of 'Matrix'): This is indeed really strange,
but differently than #nicola suggests.
It is okay to update Recommended packages such as Matrix without updating R. That's indeed one feature of these.
Matrix 1.2-3 is indeed the current version of Matrix on CRAN, which is good.
However, since Matrix 1.2-2, there is the following code in Matrix/R/zzz.R :
if(getRversion() >= "3.2.0") {
......
} else {
......
lengths <- function (x, use.names = TRUE) vapply(x, length, 1L, USE.NAMES = use.names)
}
But that code only works correctly for you, when the Matrix package is built from the source with a correct version of R, i.e. in your case with a version of R before 3.2.0.
This (correctly built) happens for all platforms but Windows (the broken by choice one).
If you really don't want (or can't easily) upgrade your version of R,
you have two other options:
downgrade your version of Matrix to the one that comes with your version of R. As you probably have installed the new Matrix replacing the old one, you need to get that and replace the newer version of Matrix. HOWEVER, I guess you would also have to downgrade lme4, and in the end you suffer too much.
Safer and in principle correct: Install the 'Rtools' collection for Windows (you need the one that matches your version of R !)
including C compiler etc, until the following works correctly
install.packages("Matrix", type = "source")
The work to do this may well be worth it. You will be able to install other R packages from their source, which is very useful anyway
(I would not want to live without this possibility if I had to work with Windows).

Related

data.table `:=` call stuck

I updated all my packages today via the RStudio package feature, which I haven't done for a while. After doing so, a line using data.table's := operator got stock in an endless loop. Please find a reproducible example below:
fun <- function(x, N, shift=0) {
if (is.na(N==length(x))) {
return(NA)
}
if (N==length(x)) {
return(NA)
} else {
x[(N+1+shift):(length(x)+shift)]
}
}
library(data.table)
DT <- data.table(ID = rep(1:1000, each=100),
QTR = rep(1:100, times=1000),
vec = list(1:100))
#Stuck in endless calculation
DT[, vec2:=list(list(fun(x=unlist(vec), N=QTR, shift=-1))), by=list(ID,QTR)]
# Takes less than a second
DT[1:nrow(DT), vec2:=list(list(fun(x=unlist(vec), N=QTR, shift=-1))), by=list(ID,QTR)]
The first call keeps running and running for me within RStudio. If I select all rows in the second call (hence, in reality, not changing anything at all), it runs in less than a second.
My sessionInfo:
> sessionInfo()
R version 3.6.3 (2020-02-29)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18363)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] data.table_1.13.0
loaded via a namespace (and not attached):
[1] compiler_3.6.3 tools_3.6.3
My questions:
Is this issue specific to my set up or is someone else able to reproduce it?
In the latter case, is it because my code is incorrect or is that a bug in a new data.table version? I notice a note from data.table about it using 2 threads since 1.13.0, but looking at ?getDTthreads()` it is not clear to me if this is related and what I could/should change to make it work again.
Glad the update resolved it!
Comment from the post:
In the change log https://rdatatable.gitlab.io/data.table/news/index.html#unreleased-data-table-v1-13-1-in-development-, bug fix 3
mentions a regression in performance with lists. Try upgrading to
1.13.1 perhaps. I have 1.12.8 and also can't replicate it

knitr, RGL and legend3d: legend3d didn't show up in the html generated by knitr

I am able to create a dynamic 3D scatter plot using rgl and knitr, but the legend created by the legend3d is missing. I guess it may be related to the implementation of hook_webgl. Any idea? Thank you.
Here are the code I used to create the 3D scatter plot:
```{r fig1, webgl=TRUE, fig.width=10 , fig.height = 10}
library(knitr)
library(rgl)
knit_hooks$set(webgl = hook_webgl)
x <- sort(rnorm(1000))
y <- rnorm(1000)
z <- rnorm(1000) + atan2(x,y)
plot3d(x, y, z, col=rep(1:2,each=500))
legend3d("topright",legend=c("Type 1","Type 2"), pch=16, col=1:2)
```
My session info:
R version 3.1.3 (2015-03-09)
Platform: i386-w64-mingw32/i386 (32-bit)
Running under: Windows Server 2008 R2 x64 (build 7601) Service Pack 1
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
other attached packages:
[1] knitr_1.11 rgl_0.95.1441 dplyr_0.4.3
loaded via a namespace (and not attached):
[1] assertthat_0.1 DBI_0.3.1 digest_0.6.8 evaluate_0.8
[5] formatR_1.2.1 highr_0.5.1 htmltools_0.3 lazyeval_0.1.10
[9] magrittr_1.5 parallel_3.1.3 R6_2.1.2 Rcpp_0.12.3
[13] rmarkdown_0.9.5 stringi_0.5-5 stringr_1.0.0 tools_3.1.3
[17] yaml_2.1.13
Looks like a bug in the rglwidget code; I'll look into it.
I recommend a few changes to your programming style. These won't help with this bug, but may save you problems later:
Use the setupKnitr() function rather than setting the knitr hook yourself. The link to knitr is likely to change, but setupKnitr() will protect you from problems.
Rather than saying webgl=TRUE in the chunk options, make a call to the rglwidget::rglwidget() function when you want to draw the plot. I'm hoping to make this call unnecessary in the future (more like what happens with regular plots), but for now it's the better tested way to do things.
Update your R. Current version is 3.2.3, with 3.2.4 due quite soon.
Use rgl and rglwidget from R-forge. They are newer than the CRAN versions, and have several bug fixes. Hopefully soon they'll have the legend bug fix too.
Added later:
This wasn't so much a bug as something that wasn't implemented. Now it is, if you use rgl version 0.95.1456 and rglwidget version 0.1.1456, both available from R-forge. Not much testing yet, so there may be more changes over the next while.

Problems using package 'minet' - could not find function mutinformation

When trying to run the sample code that is in the Minet paper / vignette I am experiencing a nunber of issues, e.g.
mim <- build.mim(discretize(syn.data), estimator)
Error in build.mim(dataset, estimator, disc, nbins):
could not find function "mutinformation"
I have also received other errors such as "unknown estimator" when trying methods prefixed with "mi." e.g. "mi.empirical."
I am running windows 8.1. Any help would be much appreciated!
EDIT 1: Additional Information
After playing around some more, the main problem I am having is when trying to use the discretize function like so:
> data(syn.data)
> disc <- "equalwidth"
> nbins <- sqrt(nrow(syn.data))
> ew.data <- discretize(syn.data, disc, nbins)
Error: could not find function "discretize"
This causes the same Error in all functions e.g. build.mim or minet which utilise discretize. I can run build.mim successfully without including discretize.
In addition, I am getting errors if I use minet (whilst excluding the discretize argument) with any of the mi.* estimation methods, e.g.
> res<-minet(syn.data,"mrnet","mi.empirical","equal width",10)
Error in build.mim(dataset, estimator, disc, nbins) :
could not find function "mutinformation"
However, running the same function with the "spearman" estimator works fine.
Edit 2: Output of sessionInfo()
> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252 LC_CTYPE=English_United Kingdom.1252 LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] minet_3.20.0
loaded via a namespace (and not attached):
[1] tools_3.1.0
discretize() is a function from the package infotheo that you can find in CRAN. There are some references to that package in the minet documentation. Maybe the authors of minet have moved some functionality to the infotheo package but since it is not a dependency it does not get installed automatically. It may be worth contacting the authors about this.
library(infotheo)
data(syn.data)
disc <- "equalwidth"
nbins <- sqrt(nrow(syn.data))
ew.data <- discretize(syn.data, disc, nbins)
The same applies for the multiinformation() function(). It is part of the infotheo package.

setMethodS3 fails to correctly reassign default function

When I create s3 methods in R 2.14.1, and then call them, the s3 objects fail to execute the methods in cases where the method has the same name as functions already loaded into the workspace (i.e. base functions). Instead it calls the base function and returns an error. This example uses 'match'. I never had this problem before today. Since I last ran this code, I installed R 3.0.2, but kept my 2.14.1 version. I ran into some trouble (different trouble) with 3.0.2 due to certain packages not being up to date in CRAN, so I reverted RStudio to 2.14.1, and then this problem cropped up. Here's an example:
rm(list=ls())
library(R.oo)
this.df<-data.frame(letter=c("A","B","C"),number=1:3)
setConstructorS3("TestClass", function(DF) {
if (missing(DF)) {
data= NA
} else {
data=DF
}
extend(Object(), "TestClass",
.data=data
)
})
setMethodS3(name="match", class="TestClass", function(this,letter,number,...){
ret = rep(TRUE,nrow(this$.data))
if (!missing(number))
ret = ret & (this$.data$number %in% number)
if (!missing(letter)){
ret = ret & (this$.data$letter %in% letter)
}
return(ret)
})
setMethodS3("get_data", "TestClass", function(this,...) {
return(this$.data[this$match(...),])
})
hope<-TestClass(this.df)
hope$match()
Error in match(this, ...) : argument "table" is missing, with no default
hope$get_data()
Here's the sessionInfo() for clues:
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] R.oo_1.13.0 R.methodsS3_1.4.2
loaded via a namespace (and not attached):
[1] tools_2.14.1
I tried a lot of combinations of the arguments in setMethodsS3 with no luck.
How can I fix this?
First, I highly recommend calling S3 methods the regular way and not via the <object>$method(...) way, e.g. match(hope) instead of hope$match(). If you do that, everything works as expected.
Second, I can reproduce this issue with R 3.0.2 and R.oo 1.17.0. There appears to be some issues using the particular method name match() here, because if you instead use match2(), calling hope$match2() works as expected. I've seen similar problems when trying to create S3 methods named assign() and get(). The latter actually generates a error if tried, e.g. "Trying to use an unsafe generic method name (trust us, it is for a good reason): get". I'll add assign() and most likely match() to the list of no-no names. DETAILS: Those functions are very special in R so one should avoid using those names. This is because, if done, S3 generic functions are created for them and all calls will be dispatched via generic functions and that is not compatible with
Finally, you should really really update your R - it's literally ancient and few people will not bother trying to help you with issues unless you run the most recent stable R version (now R 3.0.2 soon to be R 3.1.0). At a minimum, you should make sure to run the latest versions of the package (your R.methodsS3 and R.oo versions are nearly 2 and 1 years old by now with important updates since).
Hope this helps

zoo/xts - can't do math on 1-cell subsets? R hangs

I'm using latest version of R/xts/zoo on Windows: R 2.15, xts 0.8-6, zoo 1.7-7
I'm seeing the following bizarre behavior, which was not the case with prior versions:
library(xts)
data(sample_matrix)
sample.xts <- as.xts(sample_matrix)
sample.xts[1, 2] - sample.xts[2,2] # results in numeric(0)?!?!?!
(sample.xts[ 1, 2] - sample.xts[2,2])/sample.xts[3,1] # if I run this twice R locks up
Here I have subset an XTS object to a single cell. Subtraction no longer works. Also, division causes R to completely lock up.
Does anyone else see this? Is this a known bug or am I missing something? I can reproduce this on two machines.
Session Info (a few packages deleted as confidential):
R version 2.15.0 (2012-03-30)
Platform: x86_64-pc-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] parallel stats graphics utils datasets grDevices methods base
You never could subtract xts/zoo objects with non-overlapping indices. Arithmetic operations always merge before performing the operation. You need to use coredata in order for the subtraction you've written to provide the result you expect.
coredata(sample.xts[1,2]) - coredata(sample.xts[2,2])
I can replicate the second issue but I'm not sure this should be a high priority to fix, because it doesn't fit the zoo/xts idiom and would result in a completely empty xts object. Everything is fine if (some of) the indices align.
(sample.xts[1,2] - sample.xts[1,3]) / sample.xts[1,4]
(sample.xts[2,2] - sample.xts[1:2,3]) / sample.xts[2:3,4]

Resources