[Rd] detect ->
I searched and tried for hours, to no avail although it looks simple. (function(x) substitute(x))(A <- B) #A <- B (function(x) substitute(x))(A -> B) # B <- A In the first example, A occurs on the LHS, but in the second example A is somehow evaluated as if it occured on the RHS, despite my understanding that substitute() returns the unevaluated parse tree. Is there any way, or is it even possible to detect the right hand assignment, to determine whether A occurs on the LHS? Thanks in advance for any hint, Adrian — Adrian Dusa University of Bucharest Romanian Social Data Archive Soseaua Panduri nr. 90-92 050663 Bucharest sector 5 Romania https://adriandusa.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
That parser already flips -> to <- before creating the parse tree. Gabor On Mon, Apr 13, 2020 at 8:39 AM Adrian Dușa wrote: > > I searched and tried for hours, to no avail although it looks simple. > > (function(x) substitute(x))(A <- B) > #A <- B > > (function(x) substitute(x))(A -> B) > # B <- A > > In the first example, A occurs on the LHS, but in the second example A is > somehow evaluated as if it occured on the RHS, despite my understanding that > substitute() returns the unevaluated parse tree. > > Is there any way, or is it even possible to detect the right hand assignment, > to determine whether A occurs on the LHS? > > Thanks in advance for any hint, > Adrian > > — > Adrian Dusa > University of Bucharest > Romanian Social Data Archive > Soseaua Panduri nr. 90-92 > 050663 Bucharest sector 5 > Romania > https://adriandusa.eu > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors
> Duncan Murdoch > on Sun, 12 Apr 2020 08:57:14 -0400 writes: > 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 options(stringsAsFactors = > TRUE). Is this intentional? No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and alerting us about it. This will be changed ASAP. ... and it will benefit the whole R user community if quite a few good R users (as most readers of 'R-devel') would start using 'R 4.0.0 beta' routinely now --- thanks a lot in advance! Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
Adrian, Indeed, this has come up in a few places, but as Gabor says, there is no such thing as right hand assignment at any point after parsing is complete. This means the only feasible way to detect it, which a few projects do I believe, is process the code while it is still raw text, before it goes into the parser, and have clever enough regular expressions. The next question, then, is why are you trying to detect right assignment. Doing so can be arguably useful fo linting, its true. Otherwise, though, because its not really a "real thing" when the R code is being executed, its not something thats generally meaningful to detect in most cases. Best, ~G On Mon, Apr 13, 2020 at 12:52 AM Gábor Csárdi wrote: > That parser already flips -> to <- before creating the parse tree. > > Gabor > > On Mon, Apr 13, 2020 at 8:39 AM Adrian Dușa wrote: > > > > I searched and tried for hours, to no avail although it looks simple. > > > > (function(x) substitute(x))(A <- B) > > #A <- B > > > > (function(x) substitute(x))(A -> B) > > # B <- A > > > > In the first example, A occurs on the LHS, but in the second example A > is somehow evaluated as if it occured on the RHS, despite my understanding > that substitute() returns the unevaluated parse tree. > > > > Is there any way, or is it even possible to detect the right hand > assignment, to determine whether A occurs on the LHS? > > > > Thanks in advance for any hint, > > Adrian > > > > — > > Adrian Dusa > > University of Bucharest > > Romanian Social Data Archive > > Soseaua Panduri nr. 90-92 > > 050663 Bucharest sector 5 > > Romania > > https://adriandusa.eu > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
On Mon, Apr 13, 2020 at 9:23 AM Gabriel Becker wrote: [...] > This means the only feasible way to detect it, which a few projects do I > believe, is process the code while it is still raw text, before it goes into > the parser, and have clever enough regular expressions. Well, especially considering R's news raw strings with user defined delimiters, regular expressions are not the best here, I think. OTOH the source references do keep the right assignment. So if you can re-parse the data, you can detect them: ❯ x <- parse(text = "A -> B", keep.source=FALSE) ❯ x expression(B <- A) ❯ x <- parse(text = "A -> B") ❯ x expression(A -> B) ❯ getParseData(x) line1 col1 line2 col2 id parenttoken terminal text 7 11 16 7 0 exprFALSE 1 11 11 1 3 SYMBOL TRUEA 3 11 11 3 7 exprFALSE 2 13 14 2 7 RIGHT_ASSIGN TRUE -> 4 16 16 4 6 SYMBOL TRUEB 6 16 16 6 7 exprFALSE Gabor [...] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
Thank you for your replies, this actually has little to do with the regular R
code but more to signal what in my package QCA is referred to as a necessity
relation A <- B (A is necessary for B) and sufficiency A -> B (A is sufficient
for B).
If switched by the parser, A -> B becomes B <- A which makes B necessary for A,
while the intention is to signal sufficiency for B.
Capturing in a quoted string is trivial, but I am now experimenting with
substitute() to allow unquoted expressions.
This is especially useful when selecting A and B from the columns of a data
frame, using: c(A, B) instead of c("A", "B") with a lot more quotes for more
complex expressions using more columns.
I would be grateful for any pointer to a project that processes the code while
it is still raw text. I could maybe learn from their code and adapt to my use
case.
Best wishes,
Adrian
> On 13 Apr 2020, at 11:23, Gabriel Becker wrote:
>
> Adrian,
>
> Indeed, this has come up in a few places, but as Gabor says, there is no such
> thing as right hand assignment at any point after parsing is complete.
>
> This means the only feasible way to detect it, which a few projects do I
> believe, is process the code while it is still raw text, before it goes into
> the parser, and have clever enough regular expressions.
>
> The next question, then, is why are you trying to detect right assignment.
> Doing so can be arguably useful fo linting, its true. Otherwise, though,
> because its not really a "real thing" when the R code is being executed, its
> not something thats generally meaningful to detect in most cases.
>
> Best,
> ~G
>
> On Mon, Apr 13, 2020 at 12:52 AM Gábor Csárdi wrote:
> That parser already flips -> to <- before creating the parse tree.
>
> Gabor
>
> On Mon, Apr 13, 2020 at 8:39 AM Adrian Dușa wrote:
> >
> > I searched and tried for hours, to no avail although it looks simple.
> >
> > (function(x) substitute(x))(A <- B)
> > #A <- B
> >
> > (function(x) substitute(x))(A -> B)
> > # B <- A
> >
> > In the first example, A occurs on the LHS, but in the second example A is
> > somehow evaluated as if it occured on the RHS, despite my understanding
> > that substitute() returns the unevaluated parse tree.
> >
> > Is there any way, or is it even possible to detect the right hand
> > assignment, to determine whether A occurs on the LHS?
> >
> > Thanks in advance for any hint,
> > Adrian
> >
> > —
> > Adrian Dusa
> > University of Bucharest
> > Romanian Social Data Archive
> > Soseaua Panduri nr. 90-92
> > 050663 Bucharest sector 5
> > Romania
> > https://adriandusa.eu
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
—
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Long model specification causes aov() to abort with error
> Jan Hauffa > on Sat, 11 Apr 2020 15:51:49 +0200 writes: > Dear R developers, > while experimenting with repeated measures ANOVA, I found out that it is > possible to construct a model specification that is syntactically valid, > but causes aov() to abort with an error. A minimal reproducer and its > output are attached to this mail. I was able to reproduce this problem > with the latest SVN revision. > The root cause is similar to that of bug 15377: aov() calls deparse() on > the model specification. If the resulting string is too long, e.g. due > to long column names, deparse() performs line breaking and returns a > vector of strings, which aov() does not handle correctly. > The attached patch fixes this problem by making aov() call deparse1(). > It also corrects an error in the documentation of deparse1(). Thank you. What you write above seems all reasonable (and as a poster who is able to attach 3 different plain text files, named logically (i.e. without calling them .txt), I pre-judge your programming abilities to be quite high !) I'll look at the cases etc and will use your proposals. (The only question for now: why did you not take the extra step and ask for R-bugs registration and do a regular bug report -> https://www.r-project.org/bugs.html ) Thanks again, Martin Maechler ETH Zurich and R Core Team > Please CC me on replies as I am not subscribed to the mailing list. > With best regards, > Jan Hauffa > x[DELETED ATTACHMENT external: aov.diff, plain text] > x[DELETED ATTACHMENT external: aov-error.txt, plain text] > x[DELETED ATTACHMENT external: aov-testcase.R, plain text] > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 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 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 options(stringsAsFactors = > TRUE). Is this intentional? No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and alerting us about it. This will be changed ASAP. ... and it will benefit the whole R user community if quite a few good R users (as most readers of 'R-devel') would start using 'R 4.0.0 beta' routinely now --- thanks a lot in advance! Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 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 error message
On Mon, 13 Apr 2020 at 18:02, Martin Maechler
wrote:
>
> > Duncan Murdoch
> > on Sun, 12 Apr 2020 08:57:14 -0400 writes:
>
> > 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 options(stringsAsFactors =
> > TRUE). Is this intentional?
>
>
> No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and
> alerting us about it.
>
> This will be changed ASAP.
>
> ... and it will benefit the whole R user community if quite a
> few good R users (as most readers of 'R-devel') would start
> using 'R 4.0.0 beta' routinely now --- thanks a lot in advance!
>
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors
In both cases, that is as it should be. 1. expand.grid() (sic) has its main application in factorial designs, for which you want a set of factors 2. tables are factorial structures by nature. Converting factors to character would lose level order (true for 1. as well, actually) - pd > On 13 Apr 2020, at 13:01 , Karolis Koncevičius > wrote: > > 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 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 options(stringsAsFactors = >> > TRUE). Is this intentional? >> >> >> No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and >> alerting us about it. >> >> This will be changed ASAP. >> >> ... and it will benefit the whole R user community if quite a >> few good R users (as most readers of 'R-devel') would start >> using 'R 4.0.0 beta' routinely now --- thanks a lot in advance! >> >> Martin >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Poor family objects error messages
Hello,
The following code:
> binomial(identity)
Generates an error message:
Error in binomial(identity) :
link "identity" not available for binomial family; available links are
�logit�, �probit�, �cloglog�, �cauchit�, �log�
While :
> binomial("identity")
Yields an identity-binomial object that works as expected with stats::glm
The error in the first example mislead me during years. I thought
identity-binomial models were unsupported by R.
The documentation is correct but misleading too.
> The gaussian family accepts the links (as names) identity, log and inverse;
> the binomial family the
> links logit, probit, cauchit, (corresponding to logistic, normal and Cauchy
> CDFs respectively) log and
> cloglog (complementary log-log);
Without changing the language, this could be fixed by changing the error
messages to something more suggestive.
Suggestion:
Error in binomial(identity) :
name identity not available for binomial family; please use a character
string such as binomial("identity")
The documentation could be updated to insist on that.
The gaussian family accepts the links (as names) identity, log and inverse; the
binomial family the
links logit, probit, cauchit, (corresponding to logistic, normal and Cauchy
CDFs respectively) log and
cloglog (complementary log-log); [...] If the link function is given as a
character string, all families accept all link functions.
What do you think of that ?
--
Sincerely
Andr� GILLIBERT
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 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
> Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "TRUE")
> options(stringsAsFactors = c(TRUE, FALSE))
In R-devel and R 4.0.0 alpha/beta, you have
> options(stringsAsFactors = c(TRUE, FALSE))
Error in options(stringsAsFactors = c(TRUE, FALSE)) :
invalid value for 'stringsAsFactors'
> default.stringsAsFactors() # correct error message
Note that the default.stringsAsFactors() function is also
deprecated, of course. Not "formally", in the sense that its
use would give a deprecation warning {which would be *bad* as
it's still used for the default argument e.g. of read.table()},
but the help page (in R-devel and R 4.0.0 "pre-release")
has been saying for a while now
1)
Usage:
data.frame( . )
default.stringsAsFactors() # << this is deprecated !
^^
and 2) in 'Details:'
default.stringsAsFactors is a utility
... This function is *deprecated* now and will
no longer be available in the future.
and so it'd be a waste to change it unnecessarily.
Martin
> On Mon, 13 Apr 2020 at 18:02, Martin Maechler
> wrote:
>>
>> > Duncan Murdoch
>> > on Sun, 12 Apr 2020 08:57:14 -0400 writes:
>>
>> > 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 options(stringsAsFactors =
>> > TRUE). Is this intentional?
>>
>>
>> No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and
>> alerting us about it.
>>
>> This will be changed ASAP.
>>
>> ... and it will benefit the whole R user community if quite a
>> few good R users (as most readers of 'R-devel') would start
>> using 'R 4.0.0 beta' routinely now --- thanks a lot in advance!
>>
>> Martin
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] detect ->
Using => and <= instead of -> and <- would make things easier, although the
precedence would be different.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Mon, Apr 13, 2020 at 1:43 AM Adrian Dușa wrote:
> Thank you for your replies, this actually has little to do with the
> regular R code but more to signal what in my package QCA is referred to as
> a necessity relation A <- B (A is necessary for B) and sufficiency A -> B
> (A is sufficient for B).
>
> If switched by the parser, A -> B becomes B <- A which makes B necessary
> for A, while the intention is to signal sufficiency for B.
>
> Capturing in a quoted string is trivial, but I am now experimenting with
> substitute() to allow unquoted expressions.
>
> This is especially useful when selecting A and B from the columns of a
> data frame, using: c(A, B) instead of c("A", "B") with a lot more quotes
> for more complex expressions using more columns.
>
> I would be grateful for any pointer to a project that processes the code
> while it is still raw text. I could maybe learn from their code and adapt
> to my use case.
>
> Best wishes,
> Adrian
>
> > On 13 Apr 2020, at 11:23, Gabriel Becker wrote:
> >
> > Adrian,
> >
> > Indeed, this has come up in a few places, but as Gabor says, there is no
> such thing as right hand assignment at any point after parsing is complete.
> >
> > This means the only feasible way to detect it, which a few projects do I
> believe, is process the code while it is still raw text, before it goes
> into the parser, and have clever enough regular expressions.
> >
> > The next question, then, is why are you trying to detect right
> assignment. Doing so can be arguably useful fo linting, its true.
> Otherwise, though, because its not really a "real thing" when the R code is
> being executed, its not something thats generally meaningful to detect in
> most cases.
> >
> > Best,
> > ~G
> >
> > On Mon, Apr 13, 2020 at 12:52 AM Gábor Csárdi
> wrote:
> > That parser already flips -> to <- before creating the parse tree.
> >
> > Gabor
> >
> > On Mon, Apr 13, 2020 at 8:39 AM Adrian Dușa
> wrote:
> > >
> > > I searched and tried for hours, to no avail although it looks simple.
> > >
> > > (function(x) substitute(x))(A <- B)
> > > #A <- B
> > >
> > > (function(x) substitute(x))(A -> B)
> > > # B <- A
> > >
> > > In the first example, A occurs on the LHS, but in the second example A
> is somehow evaluated as if it occured on the RHS, despite my understanding
> that substitute() returns the unevaluated parse tree.
> > >
> > > Is there any way, or is it even possible to detect the right hand
> assignment, to determine whether A occurs on the LHS?
> > >
> > > Thanks in advance for any hint,
> > > Adrian
> > >
> > > —
> > > Adrian Dusa
> > > University of Bucharest
> > > Romanian Social Data Archive
> > > Soseaua Panduri nr. 90-92
> > > 050663 Bucharest sector 5
> > > Romania
> > > https://adriandusa.eu
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> —
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
> https://adriandusa.eu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors
While at it, would it be worth mentioning in the NEWS for R 4.0.0 that
options 'stringsAsFactors' is being deprecated, e.g.
$ options(stringsAsFactors = TRUE)
Warning message:
In options(stringsAsFactors = TRUE) :
'options(stringsAsFactors = TRUE)' is deprecated and will be disabled
? Currently, the news only 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().
/Henrik
On Mon, Apr 13, 2020 at 5:23 AM Martin Maechler
wrote:
>
> > 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
> > Sys.setenv("_R_CHECK_LENGTH_1_LOGIC2_" = "TRUE")
> > options(stringsAsFactors = c(TRUE, FALSE))
>
> In R-devel and R 4.0.0 alpha/beta, you have
>
> > options(stringsAsFactors = c(TRUE, FALSE))
> Error in options(stringsAsFactors = c(TRUE, FALSE)) :
> invalid value for 'stringsAsFactors'
>
>
> > default.stringsAsFactors() # correct error message
>
> Note that the default.stringsAsFactors() function is also
> deprecated, of course. Not "formally", in the sense that its
> use would give a deprecation warning {which would be *bad* as
> it's still used for the default argument e.g. of read.table()},
> but the help page (in R-devel and R 4.0.0 "pre-release")
> has been saying for a while now
>
> 1)
>
> Usage:
>
> data.frame( . )
>
> default.stringsAsFactors() # << this is deprecated !
> ^^
>
> and 2) in 'Details:'
>
> default.stringsAsFactors is a utility
> ... This function is *deprecated* now and will
> no longer be available in the future.
>
>
> and so it'd be a waste to change it unnecessarily.
> Martin
>
> > On Mon, 13 Apr 2020 at 18:02, Martin Maechler
> > wrote:
> >>
> >> > Duncan Murdoch
> >> > on Sun, 12 Apr 2020 08:57:14 -0400 writes:
> >>
> >> > 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 options(stringsAsFactors =
> >> > TRUE). Is this intentional?
> >>
> >>
> >> No! Thanks a lot for testing R 4.0.0 alpha/beta, noticing and
> >> alerting us about it.
> >>
> >> This will be changed ASAP.
> >>
> >> ... and it will benefit the whole R user community if quite a
> >> few good R users (as most readers of 'R-devel') would start
> >> using 'R 4.0.0 beta' routinely now --- thanks a lot in advance!
> >>
> >> Martin
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 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 in type.convert. I'm happy to work on the patch and run tests if that is helpful. Cheers, Arni __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
