similar to: stringsAsFactors = FALSE

Displaying 20 results from an estimated 30000 matches similar to: "stringsAsFactors = FALSE"

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
2010 Jun 05
1
Write.fwf works from Mac, throws different number of row error in Windows
Hello, I am having a problem with write.fwf in Windows. I wrote a code to ingest a number of text files with weather data in them, process them, and then output a text file with two parts: 1) a set of column names, 2) the processed data table. I wrote and tested the program on my Mac, and it worked fine. However, on the windows machine, where I intend the work to be done, when I run the
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
2007 Nov 08
1
Bug (?) in read.fwf
Hi, I'm trying to use read.fwf temp = read.fwf ("Raw data.txt", widths = c (11, 21, 10, rep (16, 6)) ,skip = 2, n = 2, stringsAsFactors = FALSE, strip.white = TRUE) but no matter what I do the strings are turned into factors. I believe it's the "n=2" parameter that causes the problem as it seems to work without this. Am I missing something? Thanks in advance,
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
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
2019 Mar 12
3
as.data.frame.table() does not recognize default.stringsAsFactors()
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" >
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
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" >
2007 Apr 26
4
select if + other questions
Hi, i am trying to read a .txt file, do a couple of select if statements on my data, and then finally use the ?table function to get frequency counts on the data. Specifically, i am looking at answering the following question: What is the frequency of Grade 7 students in the province of Alberta who are smokers? I am having some problems: 1)i cannot get the column names to show up when print
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
2012 Mar 10
1
Subsetting a data.frame -> Read in with FWF format from .DAT file
Hi there, I am having trouble subsetting a data frame by a conditional via one column (of many). I read the file into R through "read.fwf," where I specified column widths. Original data is .DAT. I then utilized "names" function to read in column headings. For one column, PRVDR_NUM, I wish to further amend the entire data set, but only have PRVDR_NUM == 050108. This is
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
2004 Jul 10
1
read.table, read.fwf, and na.strings (PR#7075)
# 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 # ###################################################### Is this intended behavior for the read.fwf(na.strings="-999")? I anticipated that
2018 May 03
0
Converting a list to a data frame
On Wed, May 2, 2018 at 11:53 AM, Jeff Newmiller <jdnewmil at dcn.davis.ca.us> wrote: > Another approach: > > ######## > library(tidyr) > L <- list( A = data.frame( x=1:2, y=3:4 ) > , B = data.frame( x=5:6, y=7:8 ) > ) > D <- data.frame( Type = names( L ) > , stringsAsFactors = FALSE > ) > D$data <- L
2018 May 02
3
Converting a list to a data frame
Another approach: ######## library(tidyr) L <- list( A = data.frame( x=1:2, y=3:4 ) , B = data.frame( x=5:6, y=7:8 ) ) D <- data.frame( Type = names( L ) , stringsAsFactors = FALSE ) D$data <- L unnest(D, data) #> Type x y #> 1 A 1 3 #> 2 A 2 4 #> 3 B 5 7 #> 4 B 6 8 ######## On Wed, 2 May 2018, Eivind K.
2017 Jul 08
0
Factor vs character in a data.frame vs vector
> On Jul 7, 2017, at 7:03 PM, John Kane <jrkrideau at yahoo.ca> wrote: > > Thanks Marc. > It never occurred to me that I would need a ""stringsAsFactors" expression in a data.frame. I could have sworn I never did before when mocking up some data but clearly I was wrong or there has been a change in R v. 3.4.1 which seems unlikely. Welcome John. Going back to
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
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