similar to: logical variables in models

Dear Bill, Thanks for pointing this difference out -- I was unaware of it. I think that the difference occurs in model.matrix.default(), which coerces character variables but not logical variables to factors. Later it treats both factors and logical variables as "factors" in that it applies contrasts to both, but unused factor levels are dropped while an unused logical level is not. I

Dear R-devel list members, I've discovered an inconsistency in how lm() and similar functions handle logical predictors as opposed to factor or character predictors. An "lm" object for a model that includes factor or character predictors includes the levels of a factor or unique values of a character predictor in the $xlevels component of the object, but not the FALSE/TRUE values

Dear Abby, > On Aug 30, 2019, at 8:20 PM, Abby Spurdle <spurdle.a at gmail.com> wrote: > >> I think that it would be better to handle factors, character predictors, and logical predictors consistently. > > "logical predictors" can be regarded as categorical or continuous (i.e. 0 or 1). > And the model matrix should be the same, either way. I think that

On Thu, Feb 21, 2019 at 7:49 AM Fox, John <jfox at mcmaster.ca> wrote: > > Dear Ben, > > Perhaps I'm missing the point, but contrasts.arg is documented to be a list. From ?model.matrix: "contrasts.arg: A list, whose entries are values (numeric matrices or character strings naming functions) to be used as replacement values for the contrasts replacement function and whose

Dear Martin and Ben, I agree that a warning is a good idea (and perhaps that wasn't clear in my response to Ben's post). Also, it would be nice to correct the omission in the help file, which as far as I could see doesn't mention that a contrast-generating function (as opposed to its quoted name) can be an element of the contrasts.arg list. Best, John > -----Original

>>>>> Fox, John >>>>> on Fri, 22 Feb 2019 17:40:15 +0000 writes: > Dear Martin and Ben, I agree that a warning is a good idea > (and perhaps that wasn't clear in my response to Ben's > post). > Also, it would be nice to correct the omission in the help > file, which as far as I could see doesn't mention that a

# Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### The multcomp functions work on "lm" objects as anticipated. They do not work on

>>>>> Ben Bolker >>>>> on Thu, 21 Feb 2019 08:18:51 -0500 writes: > On Thu, Feb 21, 2019 at 7:49 AM Fox, John <jfox at mcmaster.ca> wrote: >> >> Dear Ben, >> >> Perhaps I'm missing the point, but contrasts.arg is documented to be a list. From ?model.matrix: "contrasts.arg: A list, whose entries are

Dear Ben, Perhaps I'm missing the point, but contrasts.arg is documented to be a list. From ?model.matrix: "contrasts.arg: A list, whose entries are values (numeric matrices or character strings naming functions) to be used as replacement values for the contrasts replacement function and whose names are the names of columns of data containing factors." This isn't entirely

Dear R-devel list members, I'd like to suggest a more flexible procedure for generating contrast names. I apologise for a relatively long message -- I want my proposal to be clear. I've never liked the current approach. For example, the names generated by contr.treatment paste factor to level names with no separation between the two; contr.sum simply numbers contrasts (I recall an

I think there are two bugs in aov() that shows up when the right hand side of `formula' contains both `-1' and an Error() term, e.g., aov(y ~ a + b - 1 + Error(c), ...). Without `-1' or `Error()' there is no problem. I've included and example, and the source of aov() with suggested fixes below. The first bug (labeled BUG 1 below) creates an extra, empty stratum inside

Hi, I have run into another problem using offsets, this time with the predict function, where there seems to be a contradiction again between the behavior and the help page. On the man page for predict.lm, it says Offsets specified by offset in the fit by lm will not be included in predictions, whereas those specified by an offset term in the formula will be. While it indicates nothings about

I believe you are right, but can you please explain why anyone would want to fit this model? It differs only in the coding from aov(y ~ a + b + Error(c), data=test.df) and merely lumps together the top two strata. There is a much simpler fix: in the line if(intercept) nmstrata <- c("(Intercept)", nmstrata) remove the condition (and drop the empty stratum later if you

Dear R-helpers, In the case of two categorical factors, say a and b, once I have fixed the constrasts, the model matrix is set according to these contrasts with "lm", and the t-tests for the significance of the parameters provided by "summary" indeed concern the comparison of the model with each submodel obtained by removing the corresponding column of the model matrix.

For ordered factor the natural contrast coding would be to parametrize by the succsessive differences between levels, which does not assume equal spacing of factor levels as does the polynomial contrasts (implicitly at least). This requires the contr.cum, which could be: contr.cum <- function (n, contrasts = TRUE) { if (is.numeric(n) && length(n) == 1) levs <- 1:n

Dear R list members, I've turned up a strange discrepancy between results obtained from the lme function in the nlme package in R and results obtained with lme in S-PLUS. I'm using version 3.1-24 of nlme in R 1.4.1 under Windows 2000, and both S-PLUS 2000 and 6.0, again under Windows 2000. I've noticed discrepancies in a couple of instances. Here's one, using data from Bryk

I have a model with quant vars only and the error message does not make sense: (mod1 <- coxph(Surv(time=strt,time2=stp,event=(resp==1))~ +incpost+I(amt/1e5)+rate+strata(termfac), subset=dt<"2010-08-30", data=inc,method="efron")) Call: coxph(formula = Surv(time = strt, time2 = stp, event = (resp == 1)) ~ +incpost + I(amt/1e+05) + rate + strata(termfac),

>>>>> 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

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

Many thanks to all who helped with my question last week about how to take the output of lm() and turn it into code that can be run on systems without R (using SQL, C, etc). This is a summary of the answers, caveats, and a solution including a little Perl script I wrote to do this. Brian Ripley pointed out an important caveat to this whole process - the model.matrix could contain R functions that