Re: [Rd] Extractor function for standard deviation.
I'm not sure the idea of having a generic 'sd' extract the residual standard
deviation from a linear model quite jives with me. Personally, I think a
generic function with name like 'residSD' or something similar would be better.
Either way, I think it would be nice to have some function like this.
-roger
Rolf Turner wrote:
> I have from time to time seen inquiries on r-help in respect of
> how to obtain the estimated standard deviation from the output of
> fitting a linear model. And have had occasion to want to do this
> myself.
>
> The way I currently do it is something like summary(fit)$sigma
> (where fit is returned by lm()).
>
> It strikes me that it might be a good idea to have an extractor
> function, analogous with coef() and resid(), to dig out this value.
> This would be in keeping with the R philosophy of ``don't muck
> about with the internal components of objects returned by functions,
> because the internal structure of such objects might change in future
> releases''.
>
> I'm not sure what the name of the extractor function should be.
> One idea would be to make sd() generic, and create a function
> sd.lm() which could currently have code
>
> sd.lm <- function(x,...) {
> summary(x)$sigma
> }
>
> The sd.default() function would have the code of the current sd().
>
> Does this idea have any merit?
>
> cheers,
>
> Rolf Turner
>
> ##
> Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] __FILE__ for R
I've often missed the ability to get the directory of the currently
running script. It's actually been possible for a while:
FILE <- (function() {
attr(body(sys.function()), "srcfile")
})()
thanks to Duncan's recent changes to file parsing. This is pretty
useful for sourcing in files relative to the current script, rather
than the working directory.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] __FILE__ for R
Sorry, that should be:
FILE <- (function() {
attr(body(sys.function()), "srcfile")
})()$filename
Hadley
On Fri, Apr 4, 2008 at 10:34 AM, hadley wickham <[EMAIL PROTECTED]> wrote:
> I've often missed the ability to get the directory of the currently
> running script. It's actually been possible for a while:
>
> FILE <- (function() {
> attr(body(sys.function()), "srcfile")
> })()
>
> thanks to Duncan's recent changes to file parsing. This is pretty
> useful for sourcing in files relative to the current script, rather
> than the working directory.
>
> Hadley
>
> --
> http://had.co.nz/
>
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to tell R where to look for libgcc
I have R-261 running on a Linux 2.6 system, which has gcc-4.1.2 installed. It was working fine until the sysadmin installed an older version of gcc (3.4.6) which was required for an older app. The gcc-3.4.6 install is under /usr/local/bin. Now when a user invokes R, the error message "/opt/r-261/lib/R/bin/exec/R: /usr/local/lib/libgcc_s.so.1: version `GCC_4.0.0' not found (required by /opt/r-261/lib/R/bin/exec/R)" is generated. R is finding the old gcc version of libgcc which is in /usr/local/lib, instead of the newer one which is in lib. We've tried setting LD_LIBRARY_PATH to /lib, but that has no effect. Is there a way to force R to look in /lib for libgcc? -- Mike Waldron System Specialist RENCI at University of North Carolina – Chapel Hill CB #3455, ITS Manning, Rm 2509 Office: 919-962-9778 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cannot increase memory size to 4Gb (PR#11087)
Full_Name: Nick Henriquez Version: 2.6.2; 2.6.1 and 2.4.1 OS: Vista business 64 Submission from: (NULL) (144.82.49.16) I try to increase memory size (by copy-pasting from FAQ) --max-mem-size=1Gb at the end of the Target field (after any final double quote, and separated by a space) and changing the 1 to a 4. After double-clicking the shortcut (for modified 2.4.1 OR 2.6.1 OR 2.6.2) I get --max-mem-size=4G: too large and ignored. I have Vista business64 with 8 Gb of RAM. BioC2.1 and 2.2 complain about a lack of memory. Suggestions welcome but I think I am "alone" so far. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cannot increase memory size to 4Gb (PR#11087)
This is (sort of) correct, and as documented. What you cannot increase to 4Gb is the internal *limit* on the allocated memory size, not the 'memory size' in any sense. The rw-FAQ in R 2.6.2 patched says 'It can be set to any amount between 32Mb and 4095Mb.' as does http://cran.r-project.org/bin/windows/base/rw-FAQ.html#There-seems-to-be-a-limit-on-the-memory-it-uses_0021 The maximum size of memory for a process under Vista64 is 4Gb (4096Mb), *but* R cannot allocate all of it (not least because the R executable and DLL need to fit into it). Version 2.4.1 said (correctly) 'It can be set to any amount between 32Mb and 3Gb', because versions of Windows current at the time were limited to a 3Gb address space (and so the real limit was a little less than 3Gb). On Fri, 4 Apr 2008, [EMAIL PROTECTED] wrote: > Full_Name: Nick Henriquez > Version: 2.6.2; 2.6.1 and 2.4.1 > OS: Vista business 64 > Submission from: (NULL) (144.82.49.16) > > > I try to increase memory size (by copy-pasting from FAQ) > --max-mem-size=1Gb at the end of the Target field (after any final > double quote, and separated by a space) and changing the 1 to a 4. > > After double-clicking the shortcut (for modified 2.4.1 OR 2.6.1 OR > 2.6.2) I get --max-mem-size=4G: too large and ignored. > > I have Vista business64 with 8 Gb of RAM. BioC2.1 and 2.2 complain about > a lack of memory. Maybe, but that is not an R-bugs issue. > > Suggestions welcome but I think I am "alone" so far. R-help is available to you to ask questions about things you do not understand -- you will get a much more sympathetic response if you only use R-bugs for things you 'know for sure' are not doing what they should. -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] __FILE__ for R
Although its kludgy this previously (and still works) too:
parent.frame(2)$ofile
if called from top level within a sourced file.
On Fri, Apr 4, 2008 at 11:50 AM, hadley wickham <[EMAIL PROTECTED]> wrote:
> Sorry, that should be:
>
> FILE <- (function() {
> attr(body(sys.function()), "srcfile")
> })()$filename
>
> Hadley
>
>
> On Fri, Apr 4, 2008 at 10:34 AM, hadley wickham <[EMAIL PROTECTED]> wrote:
> > I've often missed the ability to get the directory of the currently
> > running script. It's actually been possible for a while:
> >
> > FILE <- (function() {
> > attr(body(sys.function()), "srcfile")
> > })()
> >
> > thanks to Duncan's recent changes to file parsing. This is pretty
> > useful for sourcing in files relative to the current script, rather
> > than the working directory.
> >
> > Hadley
> >
> > --
> > http://had.co.nz/
> >
>
>
>
> --
> http://had.co.nz/
>
> __
> 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] Just-in-time compiler for R
There is a new version of the just-in-time compiler for R at www.milbo.users.sonic.net/ra/index.html With just-in-time compilation enabled, the convolution example from the "Extending R" manual now runs about 30 times faster. The web page has more information. Stephen Milborrow www.milbo.users.sonic.net __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check should check date in description
I'm always forgetting to update the date in DESCRIPTION. Would it be possible to add a warning to R CMD check if it's old? Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
> hadley wickham writes: > I'm always forgetting to update the date in DESCRIPTION. Would it be > possible to add a warning to R CMD check if it's old? I recently thought about this. I see several issues. * How can we determine if it is "old"? Relative to the time when the package was uploaded to a repository? * Some developers might actually want a different date for a variety of reasons ... * What we currently say in R-exts is The optional `Date' field gives the release date of the current version of the package. It is strongly recommended to use the -mm-dd format conforming to the ISO standard. Many packages do not comply with the latter (but I have some code to sanitize most of these), and "release date" may be a moving target. The best that I could think of is to teach R CMD build to *add* a Date field if there was none. Best -k > Hadley > -- > http://had.co.nz/ > __ > 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] R CMD check should check date in description
On Fri, Apr 4, 2008 at 2:26 PM, Kurt Hornik <[EMAIL PROTECTED]> wrote: > > hadley wickham writes: > > > I'm always forgetting to update the date in DESCRIPTION. Would it be > > possible to add a warning to R CMD check if it's old? > > I recently thought about this. I see several issues. > > * How can we determine if it is "old"? Relative to the time when the > package was uploaded to a repository? > > * Some developers might actually want a different date for a variety of > reasons ... > > * What we currently say in R-exts is > > The optional `Date' field gives the release date of the current > version of the package. It is strongly recommended to use the > -mm-dd format conforming to the ISO standard. > > Many packages do not comply with the latter (but I have some code to > sanitize most of these), and "release date" may be a moving target. > > The best that I could think of is to teach R CMD build to *add* a Date > field if there was none. I agree. I think that the Date field in the DESCRIPTION file should reflect the date and time zone at which the package was built or some other date of the package maintainer's choice. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
> I recently thought about this. I see several issues. > > * How can we determine if it is "old"? Relative to the time when the > package was uploaded to a repository? > > * Some developers might actually want a different date for a variety of > reasons ... > > * What we currently say in R-exts is > > The optional `Date' field gives the release date of the current > version of the package. It is strongly recommended to use the > -mm-dd format conforming to the ISO standard. > > Many packages do not comply with the latter (but I have some code to > sanitize most of these), and "release date" may be a moving target. > > The best that I could think of is to teach R CMD build to *add* a Date > field if there was none. That sounds like a good solution to me. Otherwise, maybe just a message from R CMD check? i.e. just like failing the codetools checks, it might be perfectly ok, but you should be doing it consciously, not by mistake. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
I think its somewhat inspiring to be able to get R CMD check to the point that there are no warnings so having a situation where a warning is ok would interfere with that. On Fri, Apr 4, 2008 at 3:54 PM, hadley wickham <[EMAIL PROTECTED]> wrote: > > I recently thought about this. I see several issues. > > > > * How can we determine if it is "old"? Relative to the time when the > > package was uploaded to a repository? > > > > * Some developers might actually want a different date for a variety of > > reasons ... > > > > * What we currently say in R-exts is > > > > The optional `Date' field gives the release date of the current > > version of the package. It is strongly recommended to use the > > -mm-dd format conforming to the ISO standard. > > > > Many packages do not comply with the latter (but I have some code to > > sanitize most of these), and "release date" may be a moving target. > > > > The best that I could think of is to teach R CMD build to *add* a Date > > field if there was none. > > That sounds like a good solution to me. Otherwise, maybe just a > message from R CMD check? i.e. just like failing the codetools > checks, it might be perfectly ok, but you should be doing it > consciously, not by mistake. > > > Hadley > > > -- > http://had.co.nz/ > > __ > 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] R CMD check should check date in description
> hadley wickham writes: >> I recently thought about this. I see several issues. >> >> * How can we determine if it is "old"? Relative to the time when the >> package was uploaded to a repository? >> >> * Some developers might actually want a different date for a variety of >> reasons ... >> >> * What we currently say in R-exts is >> >> The optional `Date' field gives the release date of the current >> version of the package. It is strongly recommended to use the >> -mm-dd format conforming to the ISO standard. >> >> Many packages do not comply with the latter (but I have some code to >> sanitize most of these), and "release date" may be a moving target. >> >> The best that I could think of is to teach R CMD build to *add* a Date >> field if there was none. > That sounds like a good solution to me. Ok. However, 2.7.0 feature freeze soon ... > Otherwise, maybe just a message from R CMD check? i.e. just like > failing the codetools checks, it might be perfectly ok, but you should > be doing it consciously, not by mistake. I am working on that, too (e.g. a simple NOTE in case the date spec cannot be canonicalized, etc.). If file time stamps were realiable, we could compare these to the given date. This is I guess all we can do for e.g. CRAN's daily checking (where comparing to the date the check is run is not too useful) ... Best -k __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
I don't think having 'R CMD check' spit out a warning about the date would be all that productive. I do think it would be nice to have 'R CMD build' add a Date: field to the DESCRIPTION file if there isn't already a Date: field. And I think such an addition would solve the first problem since maintainers wouldn't have to bother maintaining a date field. -roger Kurt Hornik wrote: >> hadley wickham writes: > >> I'm always forgetting to update the date in DESCRIPTION. Would it be >> possible to add a warning to R CMD check if it's old? > > I recently thought about this. I see several issues. > > * How can we determine if it is "old"? Relative to the time when the > package was uploaded to a repository? > > * Some developers might actually want a different date for a variety of > reasons ... > > * What we currently say in R-exts is > > The optional `Date' field gives the release date of the current > version of the package. It is strongly recommended to use the > -mm-dd format conforming to the ISO standard. > > Many packages do not comply with the latter (but I have some code to > sanitize most of these), and "release date" may be a moving target. > > The best that I could think of is to teach R CMD build to *add* a Date > field if there was none. > > Best > -k > > > >> Hadley > >> -- >> http://had.co.nz/ > >> __ >> 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 > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
I agree. It sounds odd to explicitely ask someone to set the 'Date:' field and then worring because it doesn't match your precise expectation that it should equal the build time. A.F. 2008/4/4, Roger D. Peng <[EMAIL PROTECTED]>: > I don't think having 'R CMD check' spit out a warning about the date would be > all that productive. I do think it would be nice to have 'R CMD build' add a > Date: field to the DESCRIPTION file if there isn't already a Date: field. > And I > think such an addition would solve the first problem since maintainers > wouldn't > have to bother maintaining a date field. > > -roger > > > Kurt Hornik wrote: > >> hadley wickham writes: > > > >> I'm always forgetting to update the date in DESCRIPTION. Would it be > >> possible to add a warning to R CMD check if it's old? > > > > > I recently thought about this. I see several issues. > > > > * How can we determine if it is "old"? Relative to the time when the > > package was uploaded to a repository? > > > > * Some developers might actually want a different date for a variety of > > reasons ... > > > > * What we currently say in R-exts is > > > > The optional `Date' field gives the release date of the current > > version of the package. It is strongly recommended to use the > > -mm-dd format conforming to the ISO standard. > > > > Many packages do not comply with the latter (but I have some code to > > sanitize most of these), and "release date" may be a moving target. > > > > The best that I could think of is to teach R CMD build to *add* a Date > > field if there was none. > > > > > Best > > -k > > > > > > > > >> Hadley > > > >> -- > >> http://had.co.nz/ > > > >> __ > > >> 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 > > > > > -- > Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
On 4 April 2008 at 14:05, hadley wickham wrote: | I'm always forgetting to update the date in DESCRIPTION. Would it be | possible to add a warning to R CMD check if it's old? As I mentioned to Hadley in private mail, a version control system can update a field like $Date$ or $LastChangedDate$ automagically on writes or checkins. I use that as I also tend to forget to update the field manually. For SVN one must set one of the arcane propset fields. Hth, Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
Kurt Hornik wrote: >> hadley wickham writes: > >>> I recently thought about this. I see several issues. >>> >>> * How can we determine if it is "old"? Relative to the time when the >>> package was uploaded to a repository? >>> >>> * Some developers might actually want a different date for a variety of >>> reasons ... >>> >>> * What we currently say in R-exts is >>> >>> The optional `Date' field gives the release date of the current >>> version of the package. It is strongly recommended to use the >>> -mm-dd format conforming to the ISO standard. >>> >>> Many packages do not comply with the latter (but I have some code to >>> sanitize most of these), and "release date" may be a moving target. >>> >>> The best that I could think of is to teach R CMD build to *add* a Date >>> field if there was none. > >> That sounds like a good solution to me. > > Ok. However, 2.7.0 feature freeze soon ... Please no. If people want one then they should add it manually. It is optional, and some of us have explicitly opted out and would like to continue to do so. > >> Otherwise, maybe just a message from R CMD check? i.e. just like >> failing the codetools checks, it might be perfectly ok, but you should >> be doing it consciously, not by mistake. > > I am working on that, too (e.g. a simple NOTE in case the date spec > cannot be canonicalized, etc.). If file time stamps were realiable, we > could compare these to the given date. This is I guess all we can do > for e.g. CRAN's daily checking (where comparing to the date the check > is run is not too useful) ... But definitely not a warning. Robert > > Best > -k > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
> Please no. If people want one then they should add it manually. It is > optional, and some of us have explicitly opted out and would like to > continue to do so. To clarify, do you mean you have decided not to provide a date field in the DESCRIPTION file? If so, would you mind elaborating why? Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
Actually, now that I think about it, 'R CMD build' already adds the 'Packaged:' field, so perhaps it wouldn't really make sense to add yet another field with exactly the same information -roger Robert Gentleman wrote: > > Kurt Hornik wrote: >>> hadley wickham writes: I recently thought about this. I see several issues. * How can we determine if it is "old"? Relative to the time when the package was uploaded to a repository? * Some developers might actually want a different date for a variety of reasons ... * What we currently say in R-exts is The optional `Date' field gives the release date of the current version of the package. It is strongly recommended to use the -mm-dd format conforming to the ISO standard. Many packages do not comply with the latter (but I have some code to sanitize most of these), and "release date" may be a moving target. The best that I could think of is to teach R CMD build to *add* a Date field if there was none. >>> That sounds like a good solution to me. >> Ok. However, 2.7.0 feature freeze soon ... > >Please no. If people want one then they should add it manually. It > is optional, and some of us have explicitly opted out and would like to > continue to do so. > > >>> Otherwise, maybe just a message from R CMD check? i.e. just like >>> failing the codetools checks, it might be perfectly ok, but you should >>> be doing it consciously, not by mistake. >> I am working on that, too (e.g. a simple NOTE in case the date spec >> cannot be canonicalized, etc.). If file time stamps were realiable, we >> could compare these to the given date. This is I guess all we can do >> for e.g. CRAN's daily checking (where comparing to the date the check >> is run is not too useful) ... > >But definitely not a warning. > >Robert > >> Best >> -k >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
What do you think about adding this to section 1.1.1 of "Writing R Extensions", something like the following, between the paragraphs on "The 'package' and 'version' fields" and "The 'License' field: The optional 'Date' field can be either a fixed date (preferably in the -mm-dd format conforming to the ISO standard) or as "Date: $Date$" or "Date: $LastChangedDate$" so this field caries the package build date or last changed date, respectively. Spencer Dirk Eddelbuettel wrote: > On 4 April 2008 at 14:05, hadley wickham wrote: > | I'm always forgetting to update the date in DESCRIPTION. Would it be > | possible to add a warning to R CMD check if it's old? > > As I mentioned to Hadley in private mail, a version control system can update > a field like $Date$ or $LastChangedDate$ automagically on writes or > checkins. I use that as I also tend to forget to update the field manually. > For SVN one must set one of the arcane propset fields. > > Hth, Dirk > > -- > Three out of two people have difficulties with fractions. > > __ > 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] R CMD check should check date in description
hadley wickham wrote: >> Please no. If people want one then they should add it manually. It is >> optional, and some of us have explicitly opted out and would like to >> continue to do so. > > To clarify, do you mean you have decided not to provide a date field > in the DESCRIPTION file? If so, would you mind elaborating why? Sure: The date of what? > > Hadley > -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
2008/4/4, Dirk Eddelbuettel <[EMAIL PROTECTED]>: > > On 4 April 2008 at 14:05, hadley wickham wrote: > | I'm always forgetting to update the date in DESCRIPTION. Would it be > | possible to add a warning to R CMD check if it's old? > > > As I mentioned to Hadley in private mail, a version control system can update > a field like $Date$ or $LastChangedDate$ automagically on writes or > checkins. I use that as I also tend to forget to update the field manually. > For SVN one must set one of the arcane propset fields. That's not completely true. As far as I remember (git misses keywords) svn keywords are always referred only to the file they appear in. So this way the description file would contain the last date the description file itself has been modified, not the last date 'any of the package file s has been modified'. > > Hth, Dirk > > > -- > Three out of two people have difficulties with fractions. > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Antonio, Fabio Di Narzo Ph.D. student at Department of Statistical Sciences University of Bologna, Italy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] suggested minor patch for optim.R
optim ignores misspelled control parameters, so that trying
to set (e.g.) "maxint=1000" in the control argument silently
does nothing. The patch below (watch out for line breaks! also
posted at http://www.zoo.ufl.edu/bolker/optim_patch.R , and
http://www.zoo.ufl.edu/bolker/optim_new.R) adds
three lines to optim.R that issue a warning if any names of
elements of "control" fail to match the internal object that
contains the defaults.
Here is code that shows the behavior:
set.seed(1001)
x <- rnorm(10)
y <- rnorm(10,mean=1+2*x,sd=0.2)
ssqfun <- function(p) { sum((y-(p[1]+p[2]*x))^2) }
## use bogus control variable
O1 <- optim(fn=ssqfun,par=c(1,2),control=list(maxint=100))
## get new version
source(url("http://www.zoo.ufl.edu/bolker/optim_new.R";))
O2 <- optim(fn=ssqfun,par=c(1,2),control=list(maxint=100))
O3 <- optim(fn=ssqfun,par=c(1,2),control=list(maxint=100,bogus=123))
I realize this is probably too late for feature freeze for 2.7.0 (?),
but I'd appreciate any comments ...
*** optim_orig.R2008-04-04 18:55:42.0 -0400
--- optim_new.R 2008-04-04 18:58:56.0 -0400
***
*** 37,46
--- 37,50
type = 1,
lmm = 5, factr = 1e7, pgtol = 0,
tmax = 10, temp = 10.0)
+ orig.names <- names(con)
if (method == "Nelder-Mead") con$maxit <- 500
if (method == "SANN") con$maxit <- 1
con[(namc <- names(control))] <- control
+ newnames <- names(control)[!names(control) %in% orig.names]
+ if (length(newnames)>0)
+ warning(paste("unknown names in
control:",paste(newnames,collapse=", ")))
if(con$trace < 0)
warning("read the documentation for 'trace' more carefully")
if (method == "L-BFGS-B" &&
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
> > To clarify, do you mean you have decided not to provide a date field > > in the DESCRIPTION file? If so, would you mind elaborating why? > > > > Sure: The date of what? That's a good question. Another possible solution would be to remove (or down-weight the importance of) the date field, and instead use the date from the built field. This would affect the display of (at least) the output from help(package=x) and the CRAN package page. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check should check date in description
On 4 April 2008 at 23:15, Antonio, Fabio Di Narzo wrote: | 2008/4/4, Dirk Eddelbuettel <[EMAIL PROTECTED]>: | > | > On 4 April 2008 at 14:05, hadley wickham wrote: | > | I'm always forgetting to update the date in DESCRIPTION. Would it be | > | possible to add a warning to R CMD check if it's old? | > | > | > As I mentioned to Hadley in private mail, a version control system can update | > a field like $Date$ or $LastChangedDate$ automagically on writes or | > checkins. I use that as I also tend to forget to update the field manually. | > For SVN one must set one of the arcane propset fields. | | That's not completely true. As far as I remember (git misses keywords) | svn keywords are always referred only to the file they appear in. So | this way the description file would contain the last date the | description file itself has been modified, not the last date 'any of | the package file s has been modified'. I think you are correct. But as one has to augment the version number in DESCRIPTION anyway, the subsequent check-in will set the date for free. It's a kludge, but one that has been working independently of R CMD ... for years. Hth, Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
