Displaying 20 results from an estimated 40000 matches similar to: "stringsAsFactors"
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
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
2020 Apr 13
0
stringsAsFactors
>>>>> Hugh Parsonage
>>>>> on Mon, 13 Apr 2020 21:20:26 +1000 writes:
> 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
2020 Apr 20
1
stringsAsFactors and type.convert()
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
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 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 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
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 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
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"
>
2020 Apr 13
2
stringsAsFactors and type.convert()
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
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
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
2019 Mar 15
2
as.data.frame.table() does not recognize default.stringsAsFactors()
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
2019 Nov 18
2
Suggestion: Make _R_CHECK_LENGTH_1_LOGIC2_=warn the default for R 3.6.2
Hi,
I'm not sure where we are in getting CRAN packages getting their
_R_CHECK_LENGTH_1_LOGIC2_=true bugs fixed (*), but maybe it'd help to
make _R_CHECK_LENGTH_1_LOGIC2_=warn the new default in the upcoming R
3.6.2? Warnings of type:
$ R --vanilla
> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "warn")
> c(TRUE, FALSE) && TRUE
[1] TRUE
Warning message:
In
2019 Nov 18
2
Suggestion: Make _R_CHECK_LENGTH_1_LOGIC2_=warn the default for R 3.6.2
.On Mon, Nov 18, 2019 at 12:35 AM Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>
> >>>>> Henrik Bengtsson
> >>>>> on Sun, 17 Nov 2019 20:42:32 -0800 writes:
>
> > Hi,
>
> > I'm not sure where we are in getting CRAN packages getting their
> > _R_CHECK_LENGTH_1_LOGIC2_=true bugs fixed (*), but maybe
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
2016 Feb 19
0
should `data` respect default.stringsAsFactors()?
On Thu, Feb 18, 2016 at 6:03 PM, Cook, Malcolm <MEC at stowers.org> wrote:
> 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"
>>