We use the AUC package in R to evaluate the model prediction.
Sometimes, we faced the error like below:
> plot(roc(pred, yTEST))
> auc(roc(pred, yTEST))
Error in rank(prob) : argument "prob" is missing, with no default
Could anyone let us know where the error comes from ? Note that: the problem did not occur frequently. For example: we ran 10 models and it happened to 3-4 models.
It sounds like you might have loaded glmnet after AUC (glmnet also has a auc function). Just used AUC:: before the function.
Related
I'm trying to calculate estimated marginal means with the emmeans library for a gamlss object. My gamlss object comes from a zero inflated beta regression. Let's say that my model is called m1 and one of my variables is internationaltreaty, so I call:
emmeans(m1,"internationaltreaty",type="response")
and I get the following error message:
Error in match.arg(type) :
'arg' should be one of “link”, “response”, “terms”
If I use a different model object (for example glm), emmeans works with this code. To me it seems like that emmeans doesn't recognize my type argument. Has anyone experienced something similar?
Thanks.
That error does not come from trying to match your type argument. I can tell this because type = “terms” is not a possibility in emmeans. So I wonder if you get the same error even without the type argument.
Support for gamlss objects in emmeans is pretty sketchy, and I think that this is just a model that doesn’t work. You might be able to work around it using the qdrg function.
I'm using the glmulti package to do variable selection on the fixed effects of a mixed model in lme4. I had the same problem retrieving coefficients and confidence intervals that was solved by the author of the package in this thread. Namely using the coef or coef.multi gives an check.names error and the coefficients are listed as NULL when calling the predict method. So I tried the solution listed on the thread linked above, using:
setMethod('getfit', 'merMod', function(object, ...) {
summ=summary(object)$coef
summ1=summ[,1:2]
if (length(dimnames(summ)[[1]])==1) {
summ1=matrix(summ1, nr=1, dimnames=list(c("(Intercept)"),c("Estimate","Std. Error")))
}
cbind(summ1, df=rep(10000,length(fixef(object))))
})
I fixed the missed " in the original post and the code ran. But, now instead of getting
Error in data.frame(..., check.names = FALSE) :arguments imply
differing number of rows: 1, 0
I get this error for every single model...
Error in calculation of the Satterthwaite's approximation. The output
of lme4 package is returned summary from lme4 is returned some
computational error has occurred in lmerTest
I'm using lmerTest and it doesn't surprise me that it would fail if glmulti can't pull the correct info from the model. So really it's the first two lines of the error that are probably what should be focussed on.
A description of the original fix is on the developers website here. Clearly the package hasn't been updated in awhile, and yes I should probably learn a new package...but until then I'm hoping for a fix. I'll contact the developer directly through his website. But, in the mean time, has anyone tried this and found a fix?
lme4 glmulti rJava and other related packages have all been updated to the latest version.
I am facing an error when trying to run a cross validation on glmnet for family = poisson using an offset.
I managed to replicate the error with the very simple example below:
library(glmnet)
#poisson
N=500; p=20
nzc=5
x=matrix(rnorm(N*p),N,p)
beta=rnorm(nzc)
f = x[,seq(nzc)]%*%beta
mu=exp(f)
y=rpois(N,mu)
exposure=rep(0.5,length(y))
#cross validation
cv=cv.glmnet(x,y,family="poisson",offset=log(exposure),nlambda=50,nfolds=3)
which returns the following error:
Error: No newoffset provided for prediction, yet offset used in fit of
glmnet
I can't figure out what I'm doing wrong here. And wasn't able to find any help on the internet. Would anyone have ideas?
Thanks a lot!
EDIT : this issue is obsolete, and was linked to the version 2.0-12 of the glmnet package - fixed when updating to version 2.0-13
This works:
predict(cv,x,newoffset=log(exposure))
From the documentation for glmnet for the offset parameter:
If supplied, then values must also be supplied to the predict
function.
I have been doing 10X10-fold cv logistic models for a long time using homebrew code, but recently have figured that it might be nice to let caret handle the messy stuff for me.
Unfortunately, I seem to be missing some of the nuances that caret needs to be able to function.
Specifically, I keep getting this error:
>Error in { : task 1 failed - "argument is not interpretable as logical"
Please see if you can pick up what I am doing wrong...
Thanks in advance!
Data set is located here.
dataset <- read.csv("Sample Data.csv")
library(caret)
my_control <- trainControl(
method="repeatedcv",
number=10,
repeats = 10,
savePredictions="final",
classProbs=TRUE
)
This next block of code was put in there to make caret happy. My original dependent variable was a binary that I had turned into a factor, but caret had issues with the factor levels being "0" and "1". Not sure why.
dataset$Temp <- "Yes"
dataset$Temp[which(dataset$Dep.Var=="0")] <- "No"
dataset$Temp <- as.factor(dataset$Temp)
Now I (try) to get caret to run the 10X10-fold glm model for me...
testmodel <- train(Temp ~ Param.A + Param.G + Param.J + Param.O, data = dataset,
method = "glm",
trControl = my_control,
metric = "Kappa")
testmodel
> Error in { : task 1 failed - "argument is not interpretable as logical"
Though you already found a fix by updating R and caret, I'd like to point out there is (was) a bug in your code which caused the error, and which I can reproduce here with an older version of R and caret:
The savePredictions of trainControl is meant to be set to either TRUE or FALSE instead of 'final'. Seems you simply mixed it with the returnResamp parameter, which would take exactly this parameter.
BTW: R and caret have restrictions on level names of factors, which is why caret complained when you handed 0 and 1 level names for the dependent variable to it. Using a simple dataset$Dep.Var <- factor(paste0('class', dataset$Dep.Var)) should do the trick in such cases.
I don't have enough reputation to comment, so I am posting this as an answer. I ran your exact code, and it worked fine for me, twice. I did get this warning:
glm.fit: fitted probabilities numerically 0 or 1 occurred
As per the author, this error had something to do with the savePredictions parameter. Have a look at this issue:
https://github.com/topepo/caret/issues/304
Thanks to #Sumedh, I figured that the problem might not be with my code, and I updated all my packages.
Surprise! Now it works. So I wasn't crazy after all.
Sorry all for the fire drill.
I tried to apply stability function in ClustOfVar package and got an error message as below:
Error in La.svd(x, nu, nv) : error code 1 from Lapack routine 'dgesdd'.
I intended to do the variable clustering on a data set including both quantitative and qualitative variables. The R codes I uses are shown as below. At first I use the data directly (i.e., without standardization of the quantitative variables) and got the error message when running the stability function). Then I scale the quantitative variables and rerun the codes and got the same error message. Would someone give a suggestion how to fix the problem? Also, I do not think it need no step to standardize the quantitative variables because the hclustvar function should contain the standardization, right?
X.quanti<-Data4Cluster[, c(9:28)]
X.quanti2<-scale(X.quanti, center=TRUE, scale=TRUE)
X.quali<-Data4Cluster[, c(1:4,8)]
tree<-hclustvar(X.quanti,X.quali)
plot(tree)
stab<-stability(tree, B=40)
tree2<-hclustvar(X.quanti2,X.quali)
plot(tree2)
stab<-stability(tree2, B=40)
I am having exactly the same problem. The only thing that fixed it for me was changing the value of B (reducing it to 20) but I don't think it is right so I hope someone can give us a solution. My worry from searching the web is that there is a bug in the Lapack package which seems unfixable (this error is a common occurrence with various functions).
I had this error using the MASS::lda function. The error went away when I removed collinear variables from the model.