Re: [Rd] as.Date.character suggestion
On 21 Aug 2014, at 02:21 , Gabriel Becker wrote:
> Ah, my mistake, I read too fast. (My code is also wrong, embarassingly).
>
> It seems like it's behavior when you pass it "" is simply a bug, then.
>
> Sorry for the noise,
>
> ~G
>
It's not a bug, it's just that you are at the mercy of strptime() if you do
specify a format. If the format doesn't contain a conversion for some
component, you get the value corresponding to the current date and leftover
characters are just ignored, e.g.
> strptime("1-1foo","%m-%d")
[1] "2014-01-01"
and the extreme case is that a "" format gives current date, whatever the
input. On Mac OSX Mavericks anyway --- this stuff is system-dependent.
So I think Peter Langfelder is absolutely right, remove the default, which is
never used anyway, and possibly update the documentation with a more direct
reference to strptime(). This should have near-zero effect on the semantics.
Peter D.
>
>
>
> On Wed, Aug 20, 2014 at 4:59 PM, Peter Langfelder <
> peter.langfel...@gmail.com> wrote:
>
>> On Wed, Aug 20, 2014 at 4:52 PM, Gabriel Becker
>> wrote:
>>> Could do both to preserve bc...
>>>
>>> if(missing(format) || !nchar(format))
>>>
>>
>> No, the problem is that the function behaves differently when format
>> is missing than when it equals its default. Removing this difference
>> necessarily changes behaviour and hence (at least in principle) breaks
>> backward compatibility.
>>
>> Peter
>>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>
> [[alternative HTML version deleted]]
>
> __
> 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
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why R-project source code is not on Github
R-Project is missing something important in regards to its development , one simply can't ignore Github ,where collaboration is at it's best . OR If i am wrong is this the correct R-source : https://github.com/wch/r-source Is anyone thinking to bring R-project org on Github ? Maybe there might be some difficulty while porting its version system to Github . Just a suggestion . Thanks Gaurav Sehrawat http://igauravsehrawat.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why R-project source code is not on Github
On Aug 21, 2014, at 3:11 AM, Gaurav Sehrawat wrote: > R-Project is missing something important in regards to its development , > one simply can't ignore Github ,where collaboration is at it's best . > > OR If i am wrong is this the correct R-source : > https://github.com/wch/r-source > > Is anyone thinking to bring R-project org on Github ? Maybe there might be > some difficulty while porting its version system to Github . > > Just a suggestion . > > Thanks > Gaurav Sehrawat > http://igauravsehrawat.com The link you have above is to a read-only mirror (perhaps not the only one) of the R source code that is kept in the official Subversion repo: https://svn.r-project.org/R/ There are also some documents that describe R's development cycle and related processes: http://www.r-project.org/certification.html Your suggestion to move to Github is perhaps based upon a false premise, that the R community at large has the ability to directly post code/patches to the official distribution. We can contribute code and patches, primarily here on R-Devel, to the code base. However, only the members of R Core team (http://www.r-project.org/contributors.html) have write access to the SVN repo above and have to approve any such contributions. Since the current SVN based system works well for them and provides restricted write access that they can control, there is no motivation to move to an alternative version control system unless they would find it to be superior for their own development processes. That being said, there are a number of contributing projects that have packages on CRAN, that do use Github, myself included. There is also R-Forge (https://r-forge.r-project.org), which provides another SVN based platform for community package development. Regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why R-project source code is not on Github
On Thu, Aug 21, 2014 at 11:40 AM, Marc Schwartz wrote: > Your suggestion to move to Github is perhaps based upon a false premise, that > the R community at large has the ability to directly post code/patches to the > official distribution. That's not the false premise here. This is: "one simply can't ignore Github ,where collaboration is at it's best" - Gaurav Sehrawat speaking as someone often labelled a git[hub]-fanboy, even I can find reasons to debate this statement. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The behaviour of setting names differs between lists and atomic vectors
If you set the names in a list, some cat-style processing seems to happen. For example, backslashes are modified. This behaviour doesn't happen with atomic vectors. Compare, for example: setNames(1, "a\\b") ## a\\b ## 1 setNames(list(1), "a\\b") ## $`a\b` ## [1] 1 Notice that the name of the element in the list has been changed to 'a', 'backspace'. Is this behaviour intended, or a bug? -- Regards, Richie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The behaviour of setting names differs between lists and atomic vectors
On 21/08/2014 9:26 AM, Richard Cotton wrote: If you set the names in a list, some cat-style processing seems to happen. For example, backslashes are modified. This behaviour doesn't happen with atomic vectors. Compare, for example: setNames(1, "a\\b") ## a\\b ## 1 setNames(list(1), "a\\b") ## $`a\b` ## [1] 1 Notice that the name of the element in the list has been changed to 'a', 'backspace'. Is this behaviour intended, or a bug? I think there's a bug, but not in names<- (or setNames, which calls it). The bug is in the printing, as you'll see if you look at names(setNames(list(1), "a\\b")). Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date.character suggestion
Now done, for R-devel only. This can't be high priority. -pd On 21 Aug 2014, at 09:28 , peter dalgaard wrote: > > So I think Peter Langfelder is absolutely right, remove the default, which is > never used anyway, and possibly update the documentation with a more direct > reference to strptime(). This should have near-zero effect on the semantics. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The behaviour of setting names differs between lists and atomic vectors
On 21 Aug 2014, at 15:47 , Duncan Murdoch wrote: > On 21/08/2014 9:26 AM, Richard Cotton wrote: >> If you set the names in a list, some cat-style processing seems to >> happen. For example, backslashes are modified. This behaviour >> doesn't happen with atomic vectors. Compare, for example: >> >> setNames(1, "a\\b") >> ## a\\b >> ## 1 >> setNames(list(1), "a\\b") >> ## $`a\b` >> ## [1] 1 >> >> Notice that the name of the element in the list has been changed to >> 'a', 'backspace'. >> >> Is this behaviour intended, or a bug? >> > I think there's a bug, but not in names<- (or setNames, which calls it). The > bug is in the printing, as you'll see if you look at > names(setNames(list(1), "a\\b")). > Yep, slight variant: > l <- list(`a\\b`=1) > l $`a\b` [1] 1 > l$`a\b` NULL > l$`a\\b` [1] 1 > Duncan Murdoch > > __ > 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 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is using devtools::release no longer allowed?
On Tue, Aug 19, 2014 at 8:28 AM, Richard Cotton wrote: > I recently tried to submit a package to CRAN using the release > function in the devtools package and got the response: > >> The policies asked you to use the webform: do so in future. > > I think that the relevant line in the policies are: > >> When submitting a package to CRAN you should use the submission form at >> http://CRAN.R-project.org/submit.html (and not send an email). You will be >> sent >> a confirmation email which needs to be accepted. > >> If this fails, upload by anonymous ftp to ftp://CRAN.R-project.org/incoming/ >> and >> send a (plain text ASCII) email at the same time, with subject line as >> specified below. > > As far as I know, the release function uses the second method, so I > don't quite understand what the problem is. The development version of devtools uses the web form method. I will endeavour to track changes to the CRAN release process as closely as possible, but as noted elsewhere in this thread, those changes are not always well communicated. The devtools philosophy is "anything that can be automated, should be automated". You may also be eligible for the devtools guarantee: "if because of a bug in devtools a member of R-core gets angry with you, I will send you a handwritten apology note. Just forward me the email and your address, and I'll get a card in the mail." Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is using devtools::release no longer allowed?
On Tue, 19 Aug 2014, Duncan Murdoch wrote: If you use this, make sure you test it well enough to get it perfect the very first time you use it. If I were a CRAN administrator and received a series of bad submissions from someone who was working out the bugs, I would not find it difficult either technically or morally to permanently ban that user from ever submitting anything again. I think what Duncan is saying here is to make sure to log in as Dirk before testing your potentially buggy CRAN webform submitter. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is using devtools::release no longer allowed?
On Thu, 21 Aug 2014, Hadley Wickham wrote: On Tue, Aug 19, 2014 at 8:28 AM, Richard Cotton wrote: I recently tried to submit a package to CRAN using the release function in the devtools package and got the response: The policies asked you to use the webform: do so in future. I think that the relevant line in the policies are: When submitting a package to CRAN you should use the submission form at http://CRAN.R-project.org/submit.html (and not send an email). You will be sent a confirmation email which needs to be accepted. If this fails, upload by anonymous ftp to ftp://CRAN.R-project.org/incoming/ and send a (plain text ASCII) email at the same time, with subject line as specified below. As far as I know, the release function uses the second method, so I don't quite understand what the problem is. The development version of devtools uses the web form method. I will endeavour to track changes to the CRAN release process as closely as possible, but as noted elsewhere in this thread, those changes are not always well communicated. The devtools philosophy is "anything that can be automated, should be automated". You may also be eligible for the devtools guarantee: "if because of a bug in devtools a member of R-core gets angry with you, I will send you a handwritten apology note. Just forward me the email and your address, and I'll get a card in the mail." Hadley I think I'm seeing the Rcaptcha package on the horizon ... luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is using devtools::release no longer allowed?
> I think I'm seeing the Rcaptcha package on the horizon ... Devtools actually makes you perform a cognitively challenge set of tasks before submitting. One of them is: Have you read and do you agree to the the CRAN policies? (http://cran.r-project.org/web/packages/policies.html) 1: No way 2: No 3: For sure Each time the function is run both the answers are randomised so the next time you might get Have you read and do you agree to the the CRAN policies? (http://cran.r-project.org/web/packages/policies.html) 1: Not yet 2: Definitely 3: Nope The goal is to force you (as much as possible) to actually read the question and think about the answer. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why R-project source code is not on Github
On Aug 21, 2014, at 6:40 AM, Marc Schwartz wrote: > On Aug 21, 2014, at 3:11 AM, Gaurav Sehrawat > wrote: > >> R-Project is missing something important in regards to its development , >> one simply can't ignore Github ,where collaboration is at it's best . >> >> OR If i am wrong is this the correct R-source : >> https://github.com/wch/r-source >> >> Is anyone thinking to bring R-project org on Github ? Maybe there might be >> some difficulty while porting its version system to Github . >> >> Just a suggestion . >> >> Thanks >> Gaurav Sehrawat >> http://igauravsehrawat.com > > > The link you have above is to a read-only mirror (perhaps not the only one) > of the R source code that is kept in the official Subversion repo: > > https://svn.r-project.org/R/ > > There are also some documents that describe R's development cycle and related > processes: > > http://www.r-project.org/certification.html > > Your suggestion to move to Github is perhaps based upon a false premise, that > the R community at large has the ability to directly post code/patches to the > official distribution. We can contribute code and patches, primarily here on > R-Devel, to the code base. However, only the members of R Core team > (http://www.r-project.org/contributors.html) have write access to the SVN > repo above and have to approve any such contributions. > How is this different from Github? Github just makes it much easier to create and post patches to the project - it has nothing to do with write access - typically on Github the community has no write access, either. Using pull requests is certainly much less fragile than e-mails and patches are based on forked branches, so you can directly build the patched version if you want without manually applying the patch - and you see the whole history so you can pick out things logically. You can comment on individual patches to discuss them and even individual commits - often leading to a quick round trip time of revising it. Cheers, Simon > Since the current SVN based system works well for them and provides > restricted write access that they can control, there is no motivation to move > to an alternative version control system unless they would find it to be > superior for their own development processes. > > That being said, there are a number of contributing projects that have > packages on CRAN, that do use Github, myself included. There is also R-Forge > (https://r-forge.r-project.org), which provides another SVN based platform > for community package development. > > Regards, > > Marc Schwartz > > __ > 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] Inconsistent handling of data frames in min(), max(), and mean()
This inconsistency recently came to my attention:
> df <- data.frame(A = 1:10, B = rnorm(10))
> min(df)
[1] -1.768958
> max(df)
[1] 10
> mean(df)
[1] NA
Warning message:
In mean.default(df) : argument is not numeric or logical: returning NA
I recall the times where `mean(df)` would give `colMeans(df)` and this
behaviour was deemed inconsistent. It seems though that the change has
removed one inconsistency and replaced it with another.
Am I missing good reasons why there couldn't be a `mean.data.frame()`
method which worked like `max()` etc when given a data frame? Namely that
they return the required statistic *only* when presented with a data frame
of all numeric variables? E.g.
> df <- data.frame(A = 1:10, B = rnorm(10), C = factor(rep(c("A","B"), each
= 5)))
> max(df)
Error in FUN(X[[1L]], ...) :
only defined on a data frame with all numeric variables
I would expect `mean(df)` to fail with the same error as for `max(df)` with
the new example `df` but for would return the same as `mean(as.matrix(df))`
or `mean(colMeans(df))` if given an entirely numeric data frame:
> mean(colMeans(df[, 1:2]))
[1] 2.78366
> mean(as.matrix(df[, 1:2]))
[1] 2.78366
> mean(df[,1:2])
[1] 2.78366
I just can't see the sense in having `mean` work the way it does now?
Thanks,
Gavin
--
Gavin Simpson, PhD
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why R-project source code is not on Github
As someone who has merged more than a hundred pull requests on Github, I cannot agree more. Sometimes I can take patches on my mobile phone while I'm still in bed if they look reasonable and simple enough. Sometimes the patches are not worth emails back and forth, such as the correction of typos. I cannot think of anything else that is more efficient than being able to discuss the patch right in the lines of diff's. Regards, Yihui -- Yihui Xie Web: http://yihui.name On Thu, Aug 21, 2014 at 10:58 AM, Simon Urbanek wrote: > > On Aug 21, 2014, at 6:40 AM, Marc Schwartz wrote: > >> On Aug 21, 2014, at 3:11 AM, Gaurav Sehrawat >> wrote: >> >>> R-Project is missing something important in regards to its development , >>> one simply can't ignore Github ,where collaboration is at it's best . >>> >>> OR If i am wrong is this the correct R-source : >>> https://github.com/wch/r-source >>> >>> Is anyone thinking to bring R-project org on Github ? Maybe there might be >>> some difficulty while porting its version system to Github . >>> >>> Just a suggestion . >>> >>> Thanks >>> Gaurav Sehrawat >>> http://igauravsehrawat.com >> >> >> The link you have above is to a read-only mirror (perhaps not the only one) >> of the R source code that is kept in the official Subversion repo: >> >> https://svn.r-project.org/R/ >> >> There are also some documents that describe R's development cycle and >> related processes: >> >> http://www.r-project.org/certification.html >> >> Your suggestion to move to Github is perhaps based upon a false premise, >> that the R community at large has the ability to directly post code/patches >> to the official distribution. We can contribute code and patches, primarily >> here on R-Devel, to the code base. However, only the members of R Core team >> (http://www.r-project.org/contributors.html) have write access to the SVN >> repo above and have to approve any such contributions. >> > > How is this different from Github? Github just makes it much easier to create > and post patches to the project - it has nothing to do with write access - > typically on Github the community has no write access, either. Using pull > requests is certainly much less fragile than e-mails and patches are based on > forked branches, so you can directly build the patched version if you want > without manually applying the patch - and you see the whole history so you > can pick out things logically. You can comment on individual patches to > discuss them and even individual commits - often leading to a quick round > trip time of revising it. > > Cheers, > Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
