similar to: as.data.frame.table() does not recognize default.stringsAsFactors()

Displaying 20 results from an estimated 4000 matches similar to: "as.data.frame.table() does not recognize default.stringsAsFactors()"

2019 Mar 14
0
as.data.frame.table() does not recognize default.stringsAsFactors()
I have no recollection of the original rationale for as.data.frame.table, but I actually think it is fine as it is: The classifying _factors_ of a crosstable should be factors unless very specifically directed otherwise and that should not depend on the setting of an option that controls the conversion of character data. For as.data.frame.matrix, in contrast, it is the _content_ of the matrix
2009 Jun 25
2
stringsAsFactors has no impact in expand.grid()?
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
2008 Dec 19
1
How to write a Surv object to a csv-file?
Dear All, trying to write a data.frame, containing Surv objects to a csv-file I get "Error in dimnames(X) <- list(dn[[1L]], unlist(collabs, use.names = FALSE)) : length of 'dimnames' [2] not equal to array extent". See example below. May be, I overlooked something, but I expected that also data.frames containing Surv objects may be written to csv files. Is there a
2024 Mar 22
1
`as.data.frame.matrix()` can produce a data frame without a `names` attribute
>>>>> Davis Vaughan via R-devel >>>>> on Thu, 21 Mar 2024 15:10:29 -0400 writes: > Hi all, > I recently learned that it is possible for > `as.data.frame.matrix()` to produce a data frame with 0 > columns that is also entirely missing a `names` attribute, > and I think this is a bug: > ``` # No `names`, weird! >
2009 Mar 31
1
as.data.frame peculiarities
The documentation of as.data.frame is not explicit about how it generates column names for the simple vector case, but it seems to use the character form of the quoted argument, e.g. names(as.data.frame(1:3)) [1] "1:3" But there is a strange case: names(as.data.frame(c("a"))) [1] "if (stringsAsFactors) factor(x) else x" I feel fairly comfortable calling this a
2000 Mar 08
2
possible BUG with as.data.frame() and/or [.data.frame
Here is a possible BUG with as.data.frame() and/or [.data.frame which broke Michael Lapsleys RODBC-Code. Can anyone confirm it is a bug or a 'feature' of the prototype? tablename <- "abc" a <- as.data.frame(cbind("abc", 1:3)) b <- as.data.frame(cbind(tablename, 1:3)) # ok > a V1 V2 1 abc 1 2 abc 2 3 abc 3 # missing column name > b tablename 1
2012 Feb 13
3
Change dataframe-structure
Ein eingebundener Text mit undefiniertem Zeichensatz wurde abgetrennt. Name: nicht verf?gbar URL: <https://stat.ethz.ch/pipermail/r-help/attachments/20120213/d2a5afa6/attachment.pl>
2009 Jan 22
4
dimnames in pkg "ipred"
Hello List, I`m trying to make prediction using a bagged tree with the package ipred. I tried to follow the manual but I`m getting an error message. Also browsing through the list-archive I didn`t find any hint. Maybe someone can help me? selbag <- bagging(SOIL_UNIT ~., data=traindat.bin, coob=TRUE) Error in dimnames(X) <- list(dn[[1L]], unlist(collabs, use.names = FALSE)) :
2020 Apr 12
3
stringsAsFactors
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
2020 Apr 13
2
stringsAsFactors
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
2016 Feb 18
2
should `data` respect default.stringsAsFactors()?
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
2007 Sep 26
1
rpart error: "Error in dimnames(X)"
I'm using rpart to fit a tree using a large dataset: 7000 observations, 4651 variables. All but one of the variables (age) are binary. When I run the code: fit1 <- rpart(lowergi ~ ., data=dset,method="class") I get the error: Error in dimnames(X) <-list(dn[1L]], unlist(collabs, use.names=FALSE)) : Length of `dimnames' [2] not equal to array extent I have no idea
2020 Apr 13
1
stringsAsFactors
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
2008 Nov 17
2
stringsAsFactors = FALSE
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
2009 May 18
2
stringsAsFactors param in expand.grid not working
Hi all, I've (tried) to look through the bug tracker, and gmane-search the R list to see if this has been mentioned before, and it looks like it hasn't. According to the R 2.9.0 release notes[1], the expand.grid function should now take a stringsAsFactor=LOGICAL argument which controls whether or not the function coerces strings as factors. While the parameter is indeed in the
2009 May 18
2
stringsAsFactors param in expand.grid not working
Hi all, I've (tried) to look through the bug tracker, and gmane-search the R list to see if this has been mentioned before, and it looks like it hasn't. According to the R 2.9.0 release notes[1], the expand.grid function should now take a stringsAsFactor=LOGICAL argument which controls whether or not the function coerces strings as factors. While the parameter is indeed in the
2016 Feb 19
4
should `data` respect default.stringsAsFactors()?
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" >
2010 Jan 22
4
Inconsistency in as.data.frame.table for stringsAsFactors
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
2016 Feb 19
2
should `data` respect default.stringsAsFactors()?
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
2013 Feb 11
2
stringsAsFactors
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