Re: [Rd] chron vs. POSIX
On 7/14/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 7/14/2006 3:38 PM, Sebastian Luque wrote: > > Hi, > > > > One of the big decisions when writing code is how to handle dates and > > times. Gabor Grothendieck provided an excellent overview of the issue in > > his R News 4/1 (2004) article, and many users and developers are probably > > using it as a guide. The proposed guideline is to use the simplest class > > required; as Gabor put it "use Date if possible, otherwise use chron, and > > otherwise use POSIX". > > > > This seems to me a very efficient strategy, judging from my own > > experiences and those of others users. All but the simplest calculations > > with POSIX objects demand great care, due to time zone and and daylight > > savings considerations. Therefore, I've always chosen chron for > > relatively complex projects, where I don't need to deal with time zones or > > daylight savings problems. The ease with which objects can be switched > > from numeric to chron representations is a major advantage IMHO¹. > > > > If Gabor's recommendations are to be followed, wouldn't it make sense to > > include chron in base R? Given that flexibility for handling time > > variables is so fundamental, the addition of chron to base R would provide > > users everything they need to work with time, without the need to rely on > > an external package. What do others think? > > Putting something into base R essentially means that it is to be taken > over by R core. I think chron is being adequately maintained now (the R > maintainer is already a member of R core), so I don't see a need for that. > > I don't see a problem having a package on CRAN. If it's a good package > and people realize that it's good, and it remains available for others > to use, then what problem is being solved? I think the problem is that there is nothing to signal its importance. Perhaps chron should be added to the "recommended" package list. > as.vector(installed.packages(priority = "base")[,1]) [1] "base" "datasets" "graphics" "grDevices" "grid" "methods" [7] "splines" "stats" "stats4""tcltk" "tools" "utils" > as.vector(installed.packages(priority = "recommended")[,1]) [1] "boot" "class" "cluster""foreign""KernSmooth" [6] "lattice""MASS" "mgcv" "nlme" "nnet" [11] "rpart" "spatial""survival" Alternately, a new naive datetime class, i.e. a datetime class not utlitizing time zones and daylight savings time, could be created based on experience with "chron" and the existing classes such that its internal representation is like that of chron but its accessor methods are similar to existing core methods to enhance uniformity of use among the various date and time classes. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 7/15/2006 1:01 PM, Gabor Grothendieck wrote: > On 7/14/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 7/14/2006 3:38 PM, Sebastian Luque wrote: >>> Hi, >>> >>> One of the big decisions when writing code is how to handle dates and >>> times. Gabor Grothendieck provided an excellent overview of the issue in >>> his R News 4/1 (2004) article, and many users and developers are probably >>> using it as a guide. The proposed guideline is to use the simplest class >>> required; as Gabor put it "use Date if possible, otherwise use chron, and >>> otherwise use POSIX". >>> >>> This seems to me a very efficient strategy, judging from my own >>> experiences and those of others users. All but the simplest calculations >>> with POSIX objects demand great care, due to time zone and and daylight >>> savings considerations. Therefore, I've always chosen chron for >>> relatively complex projects, where I don't need to deal with time zones or >>> daylight savings problems. The ease with which objects can be switched >>> from numeric to chron representations is a major advantage IMHO¹. >>> >>> If Gabor's recommendations are to be followed, wouldn't it make sense to >>> include chron in base R? Given that flexibility for handling time >>> variables is so fundamental, the addition of chron to base R would provide >>> users everything they need to work with time, without the need to rely on >>> an external package. What do others think? >> Putting something into base R essentially means that it is to be taken >> over by R core. I think chron is being adequately maintained now (the R >> maintainer is already a member of R core), so I don't see a need for that. >> >> I don't see a problem having a package on CRAN. If it's a good package >> and people realize that it's good, and it remains available for others >> to use, then what problem is being solved? > > I think the problem is that there is nothing to signal its importance. > Perhaps > chron should be added to the "recommended" package list. I think that would be preferable to making it a base package, but it's not the only way to publicize it. Why not add something to the Wiki to compare the various possibilities for storing dates and times? Duncan Murdoch > >> as.vector(installed.packages(priority = "base")[,1]) > [1] "base" "datasets" "graphics" "grDevices" "grid" "methods" > [7] "splines" "stats" "stats4""tcltk" "tools" "utils" > >> as.vector(installed.packages(priority = "recommended")[,1]) > [1] "boot" "class" "cluster""foreign""KernSmooth" > [6] "lattice""MASS" "mgcv" "nlme" "nnet" > [11] "rpart" "spatial""survival" > > Alternately, a new naive datetime class, i.e. a datetime class not utlitizing > time zones and daylight savings time, could be created based on experience > with "chron" and the existing classes such that its internal representation > is like that of chron but its accessor methods are similar to existing core > methods to enhance uniformity of use among the various date and time classes. > > __ > 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] chron vs. POSIX
On 7/15/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 7/15/2006 1:01 PM, Gabor Grothendieck wrote: > > On 7/14/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >> On 7/14/2006 3:38 PM, Sebastian Luque wrote: > >>> Hi, > >>> > >>> One of the big decisions when writing code is how to handle dates and > >>> times. Gabor Grothendieck provided an excellent overview of the issue in > >>> his R News 4/1 (2004) article, and many users and developers are probably > >>> using it as a guide. The proposed guideline is to use the simplest class > >>> required; as Gabor put it "use Date if possible, otherwise use chron, and > >>> otherwise use POSIX". > >>> > >>> This seems to me a very efficient strategy, judging from my own > >>> experiences and those of others users. All but the simplest calculations > >>> with POSIX objects demand great care, due to time zone and and daylight > >>> savings considerations. Therefore, I've always chosen chron for > >>> relatively complex projects, where I don't need to deal with time zones or > >>> daylight savings problems. The ease with which objects can be switched > >>> from numeric to chron representations is a major advantage IMHO¹. > >>> > >>> If Gabor's recommendations are to be followed, wouldn't it make sense to > >>> include chron in base R? Given that flexibility for handling time > >>> variables is so fundamental, the addition of chron to base R would provide > >>> users everything they need to work with time, without the need to rely on > >>> an external package. What do others think? > >> Putting something into base R essentially means that it is to be taken > >> over by R core. I think chron is being adequately maintained now (the R > >> maintainer is already a member of R core), so I don't see a need for that. > >> > >> I don't see a problem having a package on CRAN. If it's a good package > >> and people realize that it's good, and it remains available for others > >> to use, then what problem is being solved? > > > > I think the problem is that there is nothing to signal its importance. > > Perhaps > > chron should be added to the "recommended" package list. > > I think that would be preferable to making it a base package, but it's > not the only way to publicize it. Why not add something to the Wiki to > compare the various possibilities for storing dates and times? As a recommended package it would be included in all binary releases ensuring access without a separate install and would provide more official endorsement. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 7/15/2006 1:37 PM, Gabor Grothendieck wrote: > On 7/15/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >> On 7/15/2006 1:01 PM, Gabor Grothendieck wrote: >>> On 7/14/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: On 7/14/2006 3:38 PM, Sebastian Luque wrote: > Hi, > > One of the big decisions when writing code is how to handle dates and > times. Gabor Grothendieck provided an excellent overview of the issue in > his R News 4/1 (2004) article, and many users and developers are probably > using it as a guide. The proposed guideline is to use the simplest class > required; as Gabor put it "use Date if possible, otherwise use chron, and > otherwise use POSIX". > > This seems to me a very efficient strategy, judging from my own > experiences and those of others users. All but the simplest calculations > with POSIX objects demand great care, due to time zone and and daylight > savings considerations. Therefore, I've always chosen chron for > relatively complex projects, where I don't need to deal with time zones or > daylight savings problems. The ease with which objects can be switched > from numeric to chron representations is a major advantage IMHO¹. > > If Gabor's recommendations are to be followed, wouldn't it make sense to > include chron in base R? Given that flexibility for handling time > variables is so fundamental, the addition of chron to base R would provide > users everything they need to work with time, without the need to rely on > an external package. What do others think? Putting something into base R essentially means that it is to be taken over by R core. I think chron is being adequately maintained now (the R maintainer is already a member of R core), so I don't see a need for that. I don't see a problem having a package on CRAN. If it's a good package and people realize that it's good, and it remains available for others to use, then what problem is being solved? >>> I think the problem is that there is nothing to signal its importance. >>> Perhaps >>> chron should be added to the "recommended" package list. >> I think that would be preferable to making it a base package, but it's >> not the only way to publicize it. Why not add something to the Wiki to >> compare the various possibilities for storing dates and times? > > As a recommended package it would be included in all binary releases > ensuring access without a separate install and would provide more > official endorsement. Yes, but that wasn't my question. A Wiki entry on dates and times would be useful whether chron is a recommended package or not. Why don't you write one based on your R News article, or at least write what you like about chron? The nice thing about wikis is that if you write anything inaccurate, someone else will come along and correct you; if you miss something, someone will add it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dweibull retuns NaN instead of Inf (PR#9080)
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-852712393-1152995865=:29235 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <[EMAIL PROTECTED]> This is debatable: according to ?dweibull and ?dgamma both pdfs are defined with support (0, Inf), so in both cases the correct answer would appear to be 0. This is in contrast to ?dexp which has the density defined on x >= 0. It seems most references have the support as [0, Inf), in which case the problem is the evaluation of x log x or equivalent. It seems we should change both the documentation and the result. On Fri, 14 Jul 2006, [EMAIL PROTECTED] wrote: > Full_Name: Göran Broström > Version: 2.3.1 > OS: Linux, ubuntu > Submission from: (NULL) (85.11.40.53) > > > > dweibull(0, 0.5, 1) > [1] NaN > Warning message: > NaNs produced in: dweibull(x, shape, scale, log) > > should give Inf (and no Warning). Compare with > > > dgamma(0, 0.5, 1) > [1] Inf > > This happens when 'shape' < 1. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 --27464147-852712393-1152995865=:29235-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chron vs. POSIX
On 7/15/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 7/15/2006 1:37 PM, Gabor Grothendieck wrote: > > On 7/15/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >> On 7/15/2006 1:01 PM, Gabor Grothendieck wrote: > >>> On 7/14/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 7/14/2006 3:38 PM, Sebastian Luque wrote: > > Hi, > > > > One of the big decisions when writing code is how to handle dates and > > times. Gabor Grothendieck provided an excellent overview of the issue > > in > > his R News 4/1 (2004) article, and many users and developers are > > probably > > using it as a guide. The proposed guideline is to use the simplest > > class > > required; as Gabor put it "use Date if possible, otherwise use chron, > > and > > otherwise use POSIX". > > > > This seems to me a very efficient strategy, judging from my own > > experiences and those of others users. All but the simplest > > calculations > > with POSIX objects demand great care, due to time zone and and daylight > > savings considerations. Therefore, I've always chosen chron for > > relatively complex projects, where I don't need to deal with time zones > > or > > daylight savings problems. The ease with which objects can be switched > > from numeric to chron representations is a major advantage IMHO¹. > > > > If Gabor's recommendations are to be followed, wouldn't it make sense to > > include chron in base R? Given that flexibility for handling time > > variables is so fundamental, the addition of chron to base R would > > provide > > users everything they need to work with time, without the need to rely > > on > > an external package. What do others think? > Putting something into base R essentially means that it is to be taken > over by R core. I think chron is being adequately maintained now (the R > maintainer is already a member of R core), so I don't see a need for > that. > > I don't see a problem having a package on CRAN. If it's a good package > and people realize that it's good, and it remains available for others > to use, then what problem is being solved? > >>> I think the problem is that there is nothing to signal its importance. > >>> Perhaps > >>> chron should be added to the "recommended" package list. > >> I think that would be preferable to making it a base package, but it's > >> not the only way to publicize it. Why not add something to the Wiki to > >> compare the various possibilities for storing dates and times? > > > > As a recommended package it would be included in all binary releases > > ensuring access without a separate install and would provide more > > official endorsement. > > Yes, but that wasn't my question. A Wiki entry on dates and times would > be useful whether chron is a recommended package or not. Why don't you > write one based on your R News article, or at least write what you like > about chron? The nice thing about wikis is that if you write anything > inaccurate, someone else will come along and correct you; if you miss > something, someone will add it. > > Duncan Murdoch > I think the R News article already sums up any knowledge I have on the subject. If anyone else has anything to add perhaps they could put that in the wiki. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Matrices given to pt? [was: [R] for loops and counters]
Hi, people.
I was a bit intrigued by the message quoted below. Indeed, if pt() is
given a matrix, it returns a matrix. Should this feature be documented?
?pt speaks about "a vector of quantiles", and says nothing about the
type of what it returns.
The same might presumably apply to other distribution-related functions.
- Forwarded message from Martyn Plummer <[EMAIL PROTECTED]> -
From: Martyn Plummer <[EMAIL PROTECTED]>
Date: Thu Apr 10 10:07:01 2003
Subject: [R] for loops and counters
Peter,
You didn't say what goes wrong, but you mind find this version more useful
tstat <- (matrix(means, k,k, byrow=TRUE) - matrix(means, k,k,byrow=FALSE))/rms
pvalue <- 2*(1-pt(abs(tstat), df=df))
pvalue[upper.tri(pvalue)]
S is designed to allow you to work with "whole objects", which means that
for loops can (and should) be avoided.
Martyn
On 05-Oct-99 Peter B. Mandeville wrote:
> I am trying to assign values to a vector (pvalue). Similar code works in C
> but not in R. What am I doing wrong?
> r <- pvalue <- 0
> for(i in (1:(k-1))){
> for(j in (i+1):k){
> r <- r+1
> tstat <- (means[i]-means[j])/rms
> pvalue[r] <- 2*(1-pt(abs(tstat),df))
> }
> }
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: [EMAIL PROTECTED]
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
- End forwarded message -
--
François Pinard http://pinard.progiciels-bpi.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrices given to pt? [was: [R] for loops and counters]
I think what is happening is that it is preserving attributes of the input.
e.g.
> x <- 1:3
> attr(x, "A") <- 23
> pt(x, 3)
[1] 0.8044989 0.9303370 0.9711656
attr(,"A")
[1] 23
Note that attribute A was preserved. Since matrices are just
vectors with a dim attribute that would imply the result. I agree
that it would be a good idea to document it if it is intended.
On 7/15/06, François Pinard <[EMAIL PROTECTED]> wrote:
> Hi, people.
>
> I was a bit intrigued by the message quoted below. Indeed, if pt() is
> given a matrix, it returns a matrix. Should this feature be documented?
> ?pt speaks about "a vector of quantiles", and says nothing about the
> type of what it returns.
>
> The same might presumably apply to other distribution-related functions.
>
> - Forwarded message from Martyn Plummer <[EMAIL PROTECTED]> -
>
> From: Martyn Plummer <[EMAIL PROTECTED]>
> Date: Thu Apr 10 10:07:01 2003
> Subject: [R] for loops and counters
>
> Peter,
>
> You didn't say what goes wrong, but you mind find this version more useful
>
> tstat <- (matrix(means, k,k, byrow=TRUE) - matrix(means, k,k,byrow=FALSE))/rms
> pvalue <- 2*(1-pt(abs(tstat), df=df))
> pvalue[upper.tri(pvalue)]
>
> S is designed to allow you to work with "whole objects", which means that
> for loops can (and should) be avoided.
>
> Martyn
>
> On 05-Oct-99 Peter B. Mandeville wrote:
> > I am trying to assign values to a vector (pvalue). Similar code works in C
> > but not in R. What am I doing wrong?
>
> > r <- pvalue <- 0
> > for(i in (1:(k-1))){
> > for(j in (i+1):k){
> > r <- r+1
> > tstat <- (means[i]-means[j])/rms
> > pvalue[r] <- 2*(1-pt(abs(tstat),df))
> > }
> > }
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !) To: [EMAIL PROTECTED]
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
>
> - End forwarded message -
>
> --
> François Pinard http://pinard.progiciels-bpi.ca
>
> __
> 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
