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

Dear list members, After further testing, I found that the following simplified version of model.matrix.lme(), which omits passing xlev to the default method, is more robust. The previous version generated spurious warnings in some circumstances. model.matrix.lme <- function(object, ...){ data <- object$data if (is.null(data)){ NextMethod(formula(object),

Dear r-devel list members, I'm posting this message here because it concerns the nlme package, which is maintained by R-core. The problem I'm about to describe is somewhere between a bug and a feature request, and so I thought it a good idea to ask here rather posting a bug report to the R bugzilla. I was made aware (by Ben Bolker) that the car::Anova() method for "lme"

Dear Ivan, Thank you for addressing my questions with your usual thoroughness. Please see below: On 2024-09-21 2:51 p.m., Ivan Krylov wrote: > [You don't often get email from ikrylov at disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Caution: External email. > > > Dear Prof. John Fox, > > ? Sat, 21 Sep 2024 12:47:49

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

There's an ancient (2003) document on the CRAN "developers' page" https://developer.r-project.org/model-fitting-functions.html that is sort of (but not exactly) what you're looking for ... On 2025-01-07 5:03 p.m., Sorkin, John wrote: > Colleagues, > > My interest is not in writing ad hoc functions (which I might use once to analyze my data), but rather what I

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