search for: 0.0184

Dear Terry, Even the behaviour of lm() and glm() isn't entirely consistent. In both cases, singularity results in NA coefficients by default, and these are reported in the model summary and coefficient vector, but not in the coefficient covariance matrix: ---------------- > mod.lm <- lm(Employed ~ GNP + Population + I(GNP + Population), + data=longley) >

Dear Metafor users, I'm conducting a metaanalysis of prevalence of a particular behaviour based on someone elses' code. I've been labouring under the impression that this: summary(rma.1<-rma(yi,vi,mods=cbind(approxmeanage,interviewmethodcode),data=mal,method="DL",knha=F,weighted=F,intercept=T)) is doing the multivariate analysis that i want, but have read that

coef() and vcov() have different dimensions if a model contains alised parameters as the following example illustrates. A search on "alised" gave noting as far as I could see. Is this a known bug? Bendix C ---------------------- Bendix Carstensen Senior Statistician Steno Diabetes Center Niels Steensens Vej 2 DK-2820 Gentofte Denmark tel: +45 44 43 87 38 mob: +45 30 75 87 38 fax: +45

>>>>> Fox, John <jfox at mcmaster.ca> >>>>> on Wed, 13 Sep 2017 22:45:07 +0000 writes: > Dear Terry, > Even the behaviour of lm() and glm() isn't entirely consistent. In both cases, singularity results in NA coefficients by default, and these are reported in the model summary and coefficient vector, but not in the coefficient covariance

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Thu, 14 Sep 2017 10:13:02 +0200 writes: >>>>> Fox, John <jfox at mcmaster.ca> >>>>> on Wed, 13 Sep 2017 22:45:07 +0000 writes: >> Dear Terry, >> Even the behaviour of lm() and glm() isn't entirely consistent. In both cases,

Dear Martin, I made three points which likely got lost because of the way I presented them: (1) Singularity is an unusual situation and should be made more prominent. It typically reflects a problem with the data or the specification of the model. That's not to say that it *never* makes sense to allow singular fits (as in the situations you mentions). I'd favour setting

>>>>> Fox, John <jfox at mcmaster.ca> >>>>> on Thu, 14 Sep 2017 13:46:44 +0000 writes: > Dear Martin, I made three points which likely got lost > because of the way I presented them: > (1) Singularity is an unusual situation and should be made > more prominent. It typically reflects a problem with the > data or the

Dear Terry, It's not surprising that different modeling functions behave differently in this respect because there's no articulated standard. Please see my response to Martin for my take on the singular.ok argument. For a highly sophisticated user like you, singular.ok=TRUE isn't problematic -- you're not going to fail to notice an NA in the coefficient vector -- but I've

Hi, I have some code I run interactively through the R interpreter and it works fine. I then run it as a script with Rscript and I get an error. The error is coming when Rscript builds a model matrix. Here is the Rscript code : #!/usr/lib/R/bin/Rscript --verbose require(MASS) options(contrasts = c("contr.treatment", "contr.poly")) .... form <- as.formula(paste(ef.var,

Dear R-philes, I am having some trouble averaging across multiple runs of a classifier in an ROC Curve. I am using the ROCR package and the plot() method. First, I initialize a list with two elements where each element is a list of predictions and labels: vowel.ROC <- list(predictions=list(), labels=list()) For every run of the classifier, I append the scores and labels to their

Dear all, I'm using R 2.8.1 under Windows Vista on a dual core 2,4 GhZ with 4 GB of RAM. I'm trying to reproduce a result out of "Analysis of Financial Time Series" by Ruey Tsay. In R I'm using the fGarch library. After fitting a ar(3)-garch(1,1)-model > model<-garchFit(~arma(3,0)+garch(1,1), analyse) I'm saving the results via > result<-model

Dear list members, the following hlm was constructed: hlm <- groupedData(laut ~ design | grpzugeh, data = imp.not.I) the grouped data object is located at and can be downloaded: www.anicca-vijja.de/lg/hlm_example.Rdata The following works: library(nlme) summary( fitlme <- lme(hlm) ) with output: ... AIC BIC logLik 425.3768 465.6087 -197.6884 Random effects:

On Fri, Sep 14, 2007 at 11:42:18PM -0700, Tanya Lattner wrote: > The 2.1 pre-release (version 1) is available for testing: > http://llvm.org/prereleases/2.1/version1/ > > [...] > > 2) Download llvm-2.1, llvm-test-2.1, and the llvm-gcc4.0 source. > Compile everything. Run "make check" and the full llvm-test suite > (make TEST=nightly report). > > Send

Target: FreeBSD 7.0-RC1 on amd64. autoconf says: configure:2122: checking build system type configure:2140: result: x86_64-unknown-freebsd7.0 [...] configure:2721: gcc -v >&5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] [...] objdir != srcdir, for both llvm and gcc. Release

LLVMers, The 2.1 pre-release (version 1) is available for testing: http://llvm.org/prereleases/2.1/version1/ I'm looking for members of the LLVM community to test the 2.1 release. There are 2 ways you can help: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download

LLVMers, The 2.2 prerelease is now available for testing: http://llvm.org/prereleases/2.2/ If anyone can help test this release, I ask that you do the following: 1) Build llvm and llvm-gcc (or use a binary). You may build release (default) or debug. You may pick llvm-gcc-4.0, llvm-gcc-4.2, or both. 2) Run 'make check'. 3) In llvm-test, run 'make TEST=nightly report'. 4) When