similar to: stringsAsFactors param in expand.grid not working

Hi I have the feeling, that the argument stringsAsFactors has no impact in the function expand.grid: a <- c("PR", "NC", "A2", "BS") b <- c(1, 0.5, 0.25, 0.125, 0.0625, 0.03125) class(expand.grid(css, fscs, stringsAsFactors=FALSE)[[1]]) [1] "factor" class(expand.grid(css, fscs, stringsAsFactors=TRUE)[[1]]) [1] "factor" Also, when

Aha... Hadn't noticed that stringsAsFactors only works via as.is in read.table. Yes, the doc should probably be fixed. The code probably not -- packages loading different data sets depending on user options is an even worse idea than hav?ng the option in the first place... (I don't mean having the possibility, I mean the default.stringsAsFactor thing). In general, read.table() gets

Hi Peter, Sorry if I was not clear. Perhaps an example will make my point: > data(iris) > class(iris$Species) [1] "factor" > write.table(iris,'data/myiris.tab') > data(myiris) > class(myiris$Species) [1] "factor" > rm(myiris) > options(stringsAsFactors = FALSE) > data(myiris) > class(myiris$Species) [1] "factor" >

Hi All, This example code ---------------- dDF <- structure(list(y = c(4.75587, 4.8451, 5.04139, 4.85733, 5.20412, 5.92428, 5.69897, 4.78958, 4, 4), t = c(0, 48, 144, 192, 240, 312, 360, 0, 48, 144), Batch = c(1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ), T = c(2, 2, 2, 2, 2, 2, 2, 2, 2, 2), pH = c(4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6, 4.6), S = c(0, 0, 0, 0, 0, 0, 0, 0, 0, 0), N = c(0, 0, 0, 0,

I use the following code to create two data.frames d1 and d2 from a list: types <- c("integer", "character", "double") nlines <- 10 d1 <- as.data.frame(lapply(types, do.call, list(nlines)), stringsAsFactor=FALSE) l2 <- lapply(types, do.call, list(nlines)) d2 <- as.data.frame(l2, stringsAsFactors=FALSE) I would expect d1 and d2 to be the

The NEWS for R 4.0.0 says "R now uses a stringsAsFactors = FALSE default, and hence by default no longer converts strings to factors in calls to data.frame() and read.table()." This seems to have been implemented by setting options(stringsAsFactors = FALSE) in the main R profile. However, setting options(stringsAsFactors = NULL) reverts to the same behavior as the old

Hiya, Probably been debated elsewhere.... I note that R's `data` function does not respect default.stringsAsFactors By my lights, it should, especially as it is documented to call read.table, which DOES respect. Oh, but: http://r.789695.n4.nabble.com/stringsAsFactors-FALSE-tp921891p921893.html Compelling. I have to agree. So, I change my mind. By my lights, `data` should then be

Further, in addition to the `val <- FALSE` patch a few hours ago by Martin, the line after should also be changed - if(!is.logical(val) || is.na(val) || length(val) != 1L) + if(!is.logical(val) || length(val) != 1L || is.na(val)) ## Consider Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "TRUE") options(stringsAsFactors = c(TRUE, FALSE)) default.stringsAsFactors() # correct

Hello, I also want to report 2 missed cases of stringsAsFactors=TRUE in base: 1. grid.expand() still uses hard stringsAsFactors=TRUE in its arguments. 2. as.data.frame.table() also keeps factors after conversion from table. >>>>>> Duncan Murdoch >>>>>> on Sun, 12 Apr 2020 08:57:14 -0400 writes: > > > The NEWS for R 4.0.0 says "R now uses

Hi all, I love the option to not automatically convert strings into factors, but there are three places that the current option doesn't work where I think it should: options(stringsAsFactors = FALSE) str(expand.grid(letters)) str(type.convert(letters)) df <- read.fwf(textConnection(paste(letters,collapse="\n")), 1) str(df) I think type.convert and read.fwf can be fixed by

I noticed that in as.data.frame.table, the stringsAsFactors argument defaults to TRUE, whereas in the other as.data.frame methods, it defaults to default.stringsAsFactors(). The documentation and implementation agree on this, so this is not a bug. However, I was wondering if this disparity was intended or if it might be some sort of unintentional oversight. If it is intentional, I wonder what

Hi, > Aha... Hadn't noticed that stringsAsFactors only works via as.is in read.table. > > Yes, the doc should probably be fixed. The code probably not Agreed. Is someone on-list authorized and willing to make the documentation change? I suppose I could learn what it takes to be a "player", but for such a trivial fix, it probably is overkill. Dissenting opinions?

Reporting a possible inconsistency or bug in handling stringsAsFactors in as.data.frame.table() Here is a simple test > options()$stringsAsFactors [1] TRUE > x<-c("a","b","c","a","b") > d<-as.data.frame(table(x)) > d x Freq 1 a 2 2 b 2 3 c 1 > class(d$x) [1] "factor" >

I think your idea to remove the warnings is excellent, and a good compromise. Characters already work fine in modeling functions except for the silly warning. It is interesting how often the defaults for a program reflect the data sets in use at the time the defaults were chosen. There are some such in my own survival package whose proper value is no longer as "obvious" as it was

I have to disagree with both Peter and Martin on this. The underneath issue is that the automatic conversion of characters to factors by the data.frame functions was the single most egregious design blunder in the Statistical Models in S book, and we are still living with it.? The stringsAsFactors option was a compromise to let users opt out of that mistake (one I had to fight hard for).??? In

Dear expeRts, The order in which the variables vary in expand.grid() is often unintuitive. I would like to suggest a 'method' slot for expand.grid() which requires only very little changes (100% backward compatible) and which allows one to control this order. Please find attached diffs against R-devel. Cheers, Marius ### ./src/library/base/R/expand.grid.R

Hello! # I have 3 vectors of values: values1<-rnorm(10) values2<-rnorm(10) values3<-rnorm(10) # In real life, all 3 vectors have a length of 25 # I create all possible combinations of 4 based on 10 elements: mycombos<-expand.grid(1:10,1:10,1:10,1:10) dim(mycombos) # Removing rows that contain pairs of identical values in any 2 of these columns: mycombos<-mycombos[!(mycombos$Var1

If read.table() is defaulting to "character" instead of "factor" data type, shouldn't type.convert() also default to "character" in R 4.0.0? This would seem like a good time to change the default to type.convert(as.is=TRUE), to align it with the new default in read.table and data.frame. I think many R >=4.0.0 users would be happy with as.is=TRUE as the default

Dear Martin, Thank you for the well-reasoned response. I realized I was rather late to make this suggestion for 4.0.0, changing a somewhat low-level function that can indeed affect packages. I was just reviewing some R user scripts that were using type.convert(), mainly on data frames. In all cases, people were passing as.is=TRUE, so I was reminded that I would not be the only user who would

--- Gabor Grothendieck <ggrothendieck at gmail.com> wrote: > Just one caveat. I personally would try to avoid > using > global options since it can cause conflicts when > two different programs assume two different settings > of the same global option and need to interact. I see this argument often, and don't buy it. In any case, for this particular option, the