Re: [Rd] R CMD check and Suggests Packages
Original message Date: Wed, 4 May 2011 09:44:14 +0200 From: Martin Maechler maech...@stat.math.ethz.ch Subject: Re: [Rd] R CMD check and Suggests Packages To: d.strbe...@garvan.org.au Cc: Martin Maechler maech...@stat.math.ethz.ch, Hervé Pagès hpa...@fhcrc.org, r-devel@r-project.org export _R_CHECK_FORCE_SUGGESTS_=false Curiously, that option isn't found in the current R-exts manual, but is clearly described in a search engine result to a page of the archived 2.5.0 (2007-04-23) version of the R-exts manual (http://pinard.progiciels-bpi.ca/libR/doc/manual/R-exts.html). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On 11-05-03 11:25 PM, Yihui Xie wrote: 1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? I have unusual needs, because I use 2 or 3 different versions of R every day. But if you're interested, the way I do it is to set up shell commands that reset the PATH appropriate to the version of R I want to use. A more usual user who always wants to use just one version from the command line could modify the PATH appropriately. I don't object to that, I just object to having R do it to unsuspecting users, because as Simon said, messing with the PATH can cause problems, and it's difficult for the R installer to know if messing with yours will cause trouble for you. In another message you asked about using Sweave. I almost never use Sweave() in R or R CMD Sweave at the command line; I have an appropriate command configured into my editors, and I run it from there. The PATH does not need to be involved. I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. I already pointed out why that is inappropriate for a lot of users. Duncan Murdoch 2. Under most circumstances I just keep the latest version of R. To maintain R code with old R versions will be more and more difficult with new features and changes coming in. Disk space is cheap, but time is not. I'm talking about the default installation directory here and I'm only wishing that the version string could be removed by default. Anyway, I think I will go to the batch files approach if these suggestions are going to be turned down. I just don't want to tell other people to run Rscript.bat under Windows and Rscript under *nix. I hope they can be consistent. Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Tue, May 3, 2011 at 8:14 PM, Duncan Murdochmurdoch.dun...@gmail.com wrote: On 03/05/2011 7:44 PM, Yihui Xie wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; Few Windows users use those commands. The ones who do are generally exactly the ones who know how to edit the PATH variable themselves. For most users (the ones who start R from the shortcut), there's no need to mess with the PATH variable. Personally, I hate programs that do that. And with R, it's now complicated, because there are 2 different directories holding executables: bin/i386 and bin/x64. (The bin directory also holds some, but that's just for back compatibility.) How could the installer know which of those to put in the PATH? At installation time, a user isn't going to know which one he/she needs. 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); Multiple installs give you the possibility of reproducing things that don't work in the latest R version. I think it's a good practice to keep multiple installs on your system if you have the space, and since disk space is cheap these days, that's not so uncommon. Duncan Murdoch I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. Thanks! Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ 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] Recursive objects
Hi all, Does anyone have a comprehensive list of recursive-type objects in R? is.recursive defines them as by exclusion: most types of objects are regarded as recursive, except for vector types, ‘NULL’ and symbols (as given by ‘as.name’). I think this that means recursive objects are: * lists * pairlists * calls * expressions Did I miss anything? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal for package that creates the isomarginal family of two-way contingency tables
Hello, I developed R code to create the isomarginal family of two-way contingency tables. The isomarginal family are all possible tables given fixed margins. It is needed for computing exact test statistics for two-way contingency tables in frequentist statistics. I need it for computing a normalization constant in a Bayesian model. I think my code can be useful for others as well so I would like to publish it as a package, but only if it is not implemented yet. I know that there is the function r2dtable in base, but it creates the tables randomly, so that some members of the family appear many times, some others not at all (exept n is extremely large). Then there is the function permatfull in package vegan, but it apparently just uses r2dtable (from the documentation). Currently my code covers only the case where the number of rows is fixed to two (with arbitrary number of columns). This makes the implementation allot easier, but is of course a limitation. However, most two-way table problems have a structure with multiple categories in one margin but a binary variable in the other. For example survival yes or no, sex female or male, or in my field, plant genomics, where most of the data is from homozygous lines, genotype AA or BB. To state my question: Is the code worth publishing? My code is based on the algorithm in: Greslin (2003) Counting and enumerating frequency tables with given margins Statistica Applicazioni I would also be interested in suggestions on how to test it. For now I used: unique(r2dtable(n,r,c)) as a reference, but to create the whole family in this way requires a huge n, even for tables of modest dimensions and counts. For example: the family of a table with dimensions 2x5, r = c(8,100) and c = c(1,2,2,98,5), r and c being the row and column margins, has 103 members (from my code). Trying to find it with: unique(r2dtable(n,r,c)) eats up more than 16Gb of memory! Thanks in advance, Frank -- Frank Technow University of Hohenheim 350 Institute of Plant Breeding, Seed Sciences, and Population Genetics 70593 Stuttgart/Germany Phone: 0049 711 459 23544 e-mail: frank.tech...@uni-hohenheim.de or frank.tech...@gmx.net __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in .Fortran Call
I have the following FORTRAN code converted to a DLL: ! my_xmean.f90 ! ! FUNCTIONS/SUBROUTINES exported from my_function.dll: ! my_function - subroutine ! subroutine my_xmean(X,N,XMEAN) ! Expose subroutine my_function to users of this DLL ! !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean ! Body of my_function DOUBLE PRECISION X(N) XMEAN=0D0 DO J=1,N XMEAN=XMEAN+X(J) END DO XMEAN=XMEAN/N RETURN end subroutine my_xmean When I call this DLL from R, it gets loaded properly but the values of XMEAN calcualted are way off: x - 1:6 .Fortran(my_xmean,as.double(X),as.integer(length(X)),double(1)) [[1]] [1] 1 2 3 4 5 6 [[2]] [1] 6 $xmean [1] 5.336073e-315 Can someone please let me what is causing this huge difference??? Thank you. Ravi -- View this message in context: http://r.789695.n4.nabble.com/Error-in-Fortran-Call-tp3495319p3495319.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursive objects
On Wed, May 4, 2011 at 3:26 PM, Hadley Wickham had...@rice.edu wrote: Hi all, Does anyone have a comprehensive list of recursive-type objects in R? is.recursive defines them as by exclusion: most types of objects are regarded as recursive, except for vector types, ‘NULL’ and symbols (as given by ‘as.name’). I think this that means recursive objects are: * lists * pairlists * calls * expressions is.recursive(environment()) # [1] TRUE Did I miss anything? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University 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] Capturing the complete unevaluated expression corresponding to function (body + formals)
Hi all, Is there any way to capture the complete unevaluated expression corresponding to a function? I want the equivalent of x - quote(function(x) x = 3) But captured after the function is created. Body and formals each captures a part, but is there a built in way to get the whole thing? f - function(x) x = 3 y - call(function, formals(f), body(f), attr(f, source)) identical(x, y) Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursive objects
Thanks to you both for reminding me about those important recursive objects! Hadley On Wed, May 4, 2011 at 7:49 AM, peter dalgaard pda...@gmail.com wrote: On May 4, 2011, at 14:35 , Kenn Konstabel wrote: On Wed, May 4, 2011 at 3:26 PM, Hadley Wickham had...@rice.edu wrote: Hi all, Does anyone have a comprehensive list of recursive-type objects in R? is.recursive defines them as by exclusion: most types of objects are regarded as recursive, except for vector types, ‘NULL’ and symbols (as given by ‘as.name’). I think this that means recursive objects are: * lists * pairlists * calls * expressions is.recursive(environment()) # [1] TRUE Closures: is.recursive(ls) [1] TRUE Did I miss anything? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University 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 -- Peter Dalgaard 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 -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in .Fortran Call
On 04/05/2011 8:26 AM, vioravis wrote: I have the following FORTRAN code converted to a DLL: ! my_xmean.f90 ! ! FUNCTIONS/SUBROUTINES exported from my_function.dll: ! my_function - subroutine ! subroutine my_xmean(X,N,XMEAN) ! Expose subroutine my_function to users of this DLL ! !DEC$ ATTRIBUTES DLLEXPORT,C,REFERENCE,ALIAS:'my_xmean_'::my_xmean ! Body of my_function DOUBLE PRECISION X(N) XMEAN=0D0 DO J=1,N XMEAN=XMEAN+X(J) END DO XMEAN=XMEAN/N RETURN end subroutine my_xmean When I call this DLL from R, it gets loaded properly but the values of XMEAN calcualted are way off: x- 1:6 .Fortran(my_xmean,as.double(X),as.integer(length(X)),double(1)) [[1]] [1] 1 2 3 4 5 6 [[2]] [1] 6 $xmean [1] 5.336073e-315 Can someone please let me what is causing this huge difference??? Thank you. I don't see a declaration of its type in the Fortran code, so it probably defaulted to REAL, not DOUBLE PRECISION. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursive objects
I never use is.recursive/is.atomic because the definition they use for an object to be recursive doesn't usually coincide with what I am interested in. (If you want to know what that definition is you can look at the source code, coerce.c:1790.) In computing on the language I would want one notion where pretty much only calls are recursive in the sense of having componets that need to be recursed into (you can see how that is handled in the byte code compiler which is in the sources as a noweb file). At the internal level, for example in the GC, _every_ object is recursive in the sence of needing to be checked for pointers to other objects, because of the attribute field. There have been discussions of this previeously -- you might search the archive. Best, luke On Wed, 4 May 2011, Hadley Wickham wrote: Hi all, Does anyone have a comprehensive list of recursive-type objects in R? is.recursive defines them as by exclusion: most types of objects are regarded as recursive, except for vector types, ‘NULL’ and symbols (as given by ‘as.name’). I think this that means recursive objects are: * lists * pairlists * calls * expressions Did I miss anything? Hadley -- Luke Tierney 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: l...@stat.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] Capturing the complete unevaluated expression corresponding to function (body + formals)
On 04/05/2011 8:38 AM, Hadley Wickham wrote: Hi all, Is there any way to capture the complete unevaluated expression corresponding to a function? I want the equivalent of x- quote(function(x) x = 3) But captured after the function is created. Body and formals each captures a part, but is there a built in way to get the whole thing? Internally, function is a function that produces a closure object. After you call it and the function is created, the inputs are gone, all you have is the result. But you can reconstruct it as you did below, because function basically just glues the parts together (and adds an environment as well). Duncan Murdoch f- function(x) x = 3 y- call(function, formals(f), body(f), attr(f, source)) identical(x, y) Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] General nil reference class object
Dear John and others,
I've been wondering about whether there's any way to indicate a nil
reference class object, which will represent no value, and be tested
for, but not fail the internal type checking. NULL is the obvious
choice (or seems so to me), but can only be used if an explicit class
union is created:
Foo - setRefClass(Foo)
Bar - setRefClass(Bar, fields=list(foo=Foo))
Bar$new(foo=NULL)
Error in as(value, Foo) :
no method or default for coercing NULL to Foo
setClassUnion(FooOrNull, c(Foo,NULL))
[1] FooOrNull
Bar - setRefClass(Bar, fields=list(foo=FooOrNull))
Bar$new(foo=NULL)
An object of class Bar
environment: 0x10392c4a0
is.null(Bar$new(foo=NULL)$foo)
[1] TRUE
Other languages allow things like MyClass object = null, and it
seems to me that it would be helpful to have a value which will always
give TRUE for is(object,AnyReferenceClassName), but will
specifically indicate a nil reference. One possible ad-hoc solution is
to define the empty object of a base class to be nil (see below),
but it seems like it would be better to have a value specifically
designed for this purpose.
nilObject - Foo$new()
is.nilObject - function (x) identical(x,nilObject)
Bar - setRefClass(Bar, fields=list(foo=Foo), methods=list(
+ initialize=function (foo=nilObject) { initFields(foo=foo) }))
is.nilObject(Bar$new()$foo)
[1] TRUE
Is there already something like this that I'm not aware of? If not,
would it be possible and generally desirable to create it?
All the best,
Jon
--
Jonathan D Clayden, PhD
Lecturer in Neuroimaging and Biophysics
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street
LONDON WC1N 1EH
United Kingdom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing the complete unevaluated expression corresponding to function (body + formals)
On Wed, May 4, 2011 at 8:07 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 04/05/2011 8:38 AM, Hadley Wickham wrote: Hi all, Is there any way to capture the complete unevaluated expression corresponding to a function? I want the equivalent of x- quote(function(x) x = 3) But captured after the function is created. Body and formals each captures a part, but is there a built in way to get the whole thing? Internally, function is a function that produces a closure object. After you call it and the function is created, the inputs are gone, all you have is the result. But you can reconstruct it as you did below, because function basically just glues the parts together (and adds an environment as well). Ok, I was getting confused because it looks like deparse and print(f, useSource = F) can print the whole thing. But looking at the source, I see that they reconstruct the function from the formals and the body too. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursive objects
On Wed, May 4, 2011 at 8:24 AM, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham had...@rice.edu wrote: Any hints as to what to search for? For recursive objects, search for recursive objects. Well, I was hoping Luke was meaning discussions about computing on the language more generally... Searching for recursive objects (with an admittedly quick skimming on titles), didn't seem to find anything relevant, except that it was me who suggested the wording Most types of objects are regarded as recursive, except for atomic vector types, ‘NULL’ and symbols (as given by ‘as.name’) Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check and Suggests Packages
In current R it is described in R-ints instead: http://r.research.att.com/man/R-ints.html#Tools But don't ask me about the rationale. That said, you can search all manuals in Google by simply using foo site:http://r.research.att.com/man/ where foo is your query Cheers, S On May 4, 2011, at 4:00 AM, Dario Strbenac wrote: Original message Date: Wed, 4 May 2011 09:44:14 +0200 From: Martin Maechler maech...@stat.math.ethz.ch Subject: Re: [Rd] R CMD check and Suggests Packages To: d.strbe...@garvan.org.au Cc: Martin Maechler maech...@stat.math.ethz.ch, Hervé Pagès hpa...@fhcrc.org, r-devel@r-project.org export _R_CHECK_FORCE_SUGGESTS_=false Curiously, that option isn't found in the current R-exts manual, but is clearly described in a search engine result to a page of the archived 2.5.0 (2007-04-23) version of the R-exts manual (http://pinard.progiciels-bpi.ca/libR/doc/manual/R-exts.html). __ 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] Curry: proposed new functional programming, er, function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis byron.el...@gmail.com wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes in really handy when using say, heatmap():
heatmap(mydata,hclustfun=Curry(hclust,method=average))
or other functions where there are ... arguments, but it's not clear
where they should end up.
--
Byron Ellis (byron.el...@gmail.com)
Oook -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 8:11 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 11-05-03 11:25 PM, Yihui Xie wrote: 1. Few Windows users use these commands does not imply they are not useful, and I have no idea how many Windows users really use them. How do you run R CMD build when you build R packages under Windows? You don't write C:/Program Files/R/R-2.13.0/bin/i386/R.exe CMD build, do you? I have unusual needs, because I use 2 or 3 different versions of R every day. But if you're interested, the way I do it is to set up shell commands that reset the PATH appropriate to the version of R I want to use. A more usual user who always wants to use just one version from the command line could modify the PATH appropriately. I don't object to that, I just object to having R do it to unsuspecting users, because as Simon said, messing with the PATH can cause problems, and it's difficult for the R installer to know if messing with yours will cause trouble for you. In another message you asked about using Sweave. I almost never use Sweave() in R or R CMD Sweave at the command line; I have an appropriate command configured into my editors, and I run it from there. The PATH does not need to be involved. I think the reason we have to mess with the PATH variable for each single software package is that Windows is Not Unix, so you may hate Windows instead of a package that modifies your PATH variable. For the choice of i386 and x64, you can let the user decide which bin path to use. I believe the number of users who frequently switch back and forth is fairly small. I already pointed out why that is inappropriate for a lot of users. The batchfiles handle this using Rversions.bat. Without arguments it lists the available R versions and with an argument it makes that the current version of R so that Rgui.bat, R.bat, invoke that version. Rversions.bat works by running the appropriate RSetReg.exe utility (which is a utility that is included in every R distribution). Of course if you just want to run a specific version of Rgui each version has a separate icon on the desktop so one can select the version of interest that way too. I personally keep about half a dozen back versions of R for the reasons others have mentioned and these would include one R-13.x version, one R-12.x version, etc. I literally use x in the name since only the most recent version in any such series is stored. That is, when a new R-2.13.x comes out I just install it over the existing R-2.13.x: Directory of C:\Program Files\R 31/03/2010 02:37 PMDIR R-2.10.x 01/06/2010 01:03 PMDIR R-2.11.x 22/03/2011 03:25 PMDIR R-2.12.x 26/04/2011 01:45 PMDIR R-2.13.x -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
I too would like this (being an Indian!).
Here is an example that came up just yesterday with regards to solving a
quadrature problem using the cubature package. The adaptIntegrate function
does not allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it also
tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
require(cubature)
f - function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a - 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
Best,
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins
University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis byron.el...@gmail.com wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes in really handy when using say, heatmap():
heatmap(mydata,hclustfun=Curry(hclust,method=average))
or other functions where there are ... arguments, but it's not clear
where they should end up.
--
Byron Ellis (byron.el...@gmail.com)
Oook -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
-Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of Gabor Grothendieck Sent: May-04-11 10:35 AM To: Duncan Murdoch Cc: R-devel Subject: Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows [snip] I personally keep about half a dozen back versions of R for the reasons others have mentioned and these would include one R-13.x version, one R- 12.x version, etc. I literally use x in the name since only the most recent version in any such series is stored. That is, when a new R-2.13.x comes out I just install it over the existing R-2.13.x: Directory of C:\Program Files\R 31/03/2010 02:37 PMDIR R-2.10.x 01/06/2010 01:03 PMDIR R-2.11.x 22/03/2011 03:25 PMDIR R-2.12.x 26/04/2011 01:45 PMDIR R-2.13.x Do you keep the RTools version specific to each version of R installed too? If so, how do you manage that so that each version of R finds the right version of RTools when it needs it? I don't use RTools much, but I need it to install some fo the packages I use from source since there are no binary distributions for them (for 64 bit Windows). I don't typically keep any more than two versions of R on my machine at any one time, but I don't remove an older version until I have verified that my R scripts work fine in the latest release. So usually there is only one version on my machine, but there will be two for a short while after a new release. But, my normal practice, as I describe here, would be disrupted if R's installer wrote R's bin path to my system path (in fact, I hate that for any software I use, even though in some cases there's no way to avoid it). Thanks Ted __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
On 04/05/2011 10:40 AM, Ravi Varadhan wrote:
I too would like this (being an Indian!).
Here is an example that came up just yesterday with regards to solving a quadrature
problem using the cubature package. The adaptIntegrate function does not
allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it also
tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
require(cubature)
f- function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a- 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
Two objections:
1. I don't see how that is preferable to
adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)
2. There seems to be confusion about what currying means. The
Wikipedia page http://en.wikipedia.org/wiki/Currying indicates that
the function Curry() defined above is really doing partial function
application, not currying. I'm in no position to judge whether Byron
got it right or Wikipedia did, but this suggests to me that the name
Curry is inappropriate, since at least some people who know what
currying is would not guess that it does what it does.
Duncan Murdoch
Best,
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins
University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellisbyron.el...@gmail.com wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes in really handy when using say, heatmap():
heatmap(mydata,hclustfun=Curry(hclust,method=average))
or other functions where there are ... arguments, but it's not clear
where they should end up.
--
Byron Ellis (byron.el...@gmail.com)
Oook -- The Librarian
__
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] Curry: proposed new functional programming, er, function.
On Wed, May 4, 2011 at 10:40 AM, Ravi Varadhan rvarad...@jhmi.edu wrote:
I too would like this (being an Indian!).
Here is an example that came up just yesterday with regards to solving a
quadrature problem using the cubature package. The adaptIntegrate function
does not allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it also
tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
require(cubature)
f - function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a - 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
Here is another approach. If we preface any function with gsubfn's fn$
then it will turn formulas (subject to certain rules to determine
which to pay attention to) into functions.
1. Here it is applied to the cubature example
library(cubature)
library(gsubfn)
Loading required package: proto
fn$adaptIntegrate(~ f(x, 0.2), lower=0, upper=2)
$integral
[1] 0.4677446
$error
[1] 1.247382e-14
$functionEvaluations
[1] 15
$returnCode
[1] 0
2. and here is the heatmap example redone. The example line is to
compute x so that the code is self contained:
library(gsubfn)
example(heatmap)
fn$heatmap(x, hclustfun = ~ hclust(x, method=average))
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
On Wed, 4 May 2011, Ravi Varadhan wrote:
I too would like this (being an Indian!).
I would not.
Here is an example that came up just yesterday with regards to solving a quadrature
problem using the cubature package. The adaptIntegrate function does not
allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it also
tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
This has quite different behavior with respect to evaluation/lazy
evaluation than an analogous anonymous function. In addition, do.call
has some fairly strange aspect so it with respect to how it intereacts
with sys.xyz functions, and does not do what you want in many cases I
care about when quote = FALSE, as is the default. Adding this would
create more problems than is solves.
require(cubature)
f - function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a - 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
Yes -- as do a number of other variations.
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
Of course not -- why would anyone think it would?
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
The _concept_ of currying is useful, and maybe more can be done to
provide guidance and education on how to do it, but adding a function
that sometimes works and somesimes does surprising things is not the
way to go.
Best,
luke
Best,
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins
University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er, function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellis byron.el...@gmail.com wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes in really handy when using say, heatmap():
heatmap(mydata,hclustfun=Curry(hclust,method=average))
or other functions where there are ... arguments, but it's not clear
where they should end up.
--
Byron Ellis (byron.el...@gmail.com)
Oook -- The Librarian
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
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: l...@stat.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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
If I am already able to open R, there is no need to post the request here. I want to be able to run R without knowing where it is from another software package. Your batch files fit in this purpose, and the only problem is it is a little bit slower since it takes time to look for R in the system via several approaches. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, May 4, 2011 at 12:28 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: On Wed, May 4, 2011 at 1:04 AM, Yihui Xie x...@yihui.name wrote: Thanks! But I'm sorry this is not what I wanted. I just hope we can call R as a command like we do under *nix -- this will make it easier for *other* software packages to find R. You asked for an R program that gives the ability to run R.exe, Rscript.exe, etc. from the command line and that indeed is what it enables in the spawned session. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 11:15 AM, Yihui Xie x...@yihui.name wrote: If I am already able to open R, there is no need to post the request here. I want to be able to run R without knowing where it is from another software package. Your batch files fit in this purpose, and the only problem is it is a little bit slower since it takes time to look for R in the system via several approaches. Not on my laptop (which is not particularly powerful). Rgui.bat brings up R nearly instantaneously. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On Wed, May 4, 2011 at 10:53 AM, Ted Byers r.ted.by...@gmail.com wrote: -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r- project.org] On Behalf Of Gabor Grothendieck Sent: May-04-11 10:35 AM To: Duncan Murdoch Cc: R-devel Subject: Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows [snip] I personally keep about half a dozen back versions of R for the reasons others have mentioned and these would include one R-13.x version, one R- 12.x version, etc. I literally use x in the name since only the most recent version in any such series is stored. That is, when a new R-2.13.x comes out I just install it over the existing R-2.13.x: Directory of C:\Program Files\R 31/03/2010 02:37 PM DIR R-2.10.x 01/06/2010 01:03 PM DIR R-2.11.x 22/03/2011 03:25 PM DIR R-2.12.x 26/04/2011 01:45 PM DIR R-2.13.x Do you keep the RTools version specific to each version of R installed too? If so, how do you manage that so that each version of R finds the right version of RTools when it needs it? I don't use RTools much, but I need it to install some fo the packages I use from source since there are no binary distributions for them (for 64 bit Windows). I don't typically keep any more than two versions of R on my machine at any one time, but I don't remove an older version until I have verified that my R scripts work fine in the latest release. So usually there is only one version on my machine, but there will be two for a short while after a new release. But, my normal practice, as I describe here, would be disrupted if R's installer wrote R's bin path to my system path (in fact, I hate that for any software I use, even though in some cases there's no way to avoid it). Thanks Ted Typically I do my development on the latest version of R so I only need one version of Rtools. The older versions of R are just for checking older software. There is a program RtoolsVersion.bat in the batchfiles that will tell you which version of Rtools you have (which it finds by first looking in the registry and if not found there looks for an R_TOOLS environment variable and if still not found looks for C:\Rtools): C:\tmp2RtoolsVersion RtoolsVersion.bat: Rtools found at: c:\Rtools Rtools version 2.13.0.1901 (There is also Rtools.bat that will temporarily add Rtools to your path (although if you use Rcmd.bat, R.bat, etc. then they can find Rtools without it being on the path so mostly one does not need to use Rtools.bat). If people wanted to have multiple versions of Rtools, Rtools would ideally have a tool similar to R's own RSetReg.exe . Another possibility would be to turn Rtools into an R package so that R's library mechanism handled the versioning. Regarding permanently putting R on the path, I agree that it would be annoying having R permanently there and for that reason the batchfiles do not do that. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
In terms of a personal use, that is absolutely fine. From the perspective of a developer, you cannot stop a user from upgrading to newer versions. Perhaps it is a matter of personal taste; I'm worried more about adapting to latest versions than maintaining old versions. If the new versions works fine, I will remove all the old versions. I have never run into troubles in which I have no choice but to use the old version of R. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, May 4, 2011 at 12:46 AM, Wincent ronggui.hu...@gmail.com wrote: I also prefer to keep the old versions. Sometimes, I have spent time to set up the system with older version and don't want to update to the latest (e.g. the new RGtk2 needs updated GTk2 as well) because the older still works and I don't need the new features. Regards Ronggui __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tkrplot not working in R 2.13.0
The tkrplot package is not working in version 2.13.0 for windows. I contacted the maintainer who unfortunately does not have easy access to a windows computer and says that it is working on the other platforms. I traced the problem down to the line in the .First.lib function: .Tcl(paste(load, file, Rplot)) With file being C:/Program Files/R/R-2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system. I did check that the file exists and it can even be loaded using dyn.load, but when running the .Tcl command by hand it produces the following error: Error in structure(.External(dotTcl, ..., PACKAGE = tcltk), class = tclObj) : [tcl] could not find interpreter Rplot. It works in previous versions of R, so I am guessing that this is due to some change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the new R, or possibly something else. Does anyone else have any insights? sessionInfo() R version 2.13.0 (2011-04-13) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] tcltk stats graphics grDevices utils datasets methods [8] base other attached packages: [1] TeachingDemos_2.7 tkrplot_0.0-19 loaded via a namespace (and not attached): [1] tools_2.13.0 Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
The _concept_ of currying is useful, and maybe more can be done to
provide guidance and education on how to do it, but adding a function
that sometimes works and somesimes does surprising things is not the
way to go.
What about an alternative approach?
Curry - function(FUN, ...) {
args - match.call(expand.dots = FALSE)$...
args$... - as.name(...)
curry_call - as.call(c(list(as.name(FUN)), args))
function(...) {
eval(curry_call)
}
}
Or maybe
Curry - function(FUN, ...) {
args - match.call(expand.dots = FALSE)$...
args$... - as.name(...)
curry_call - as.call(c(list(as.name(FUN)), args))
eval(bquote(function(...) .(curry_call)))
}
I think this is pretty close to what you'd get if you made an
anonymous function (but I'm probably missing something)
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
# Use of Curry adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2) Two objections: 1. I don't see how that is preferable to adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2) It's less typing? A more helpful use is when you have a list of functions: funs - list( sum = sum, mean = mean, median = median ) with Curry function you can do : funs2 - lapply(funs, Curry, na.rm = TRUE) as opposed to funs2 - list( sum = function(x, ...) sum(x, ..., na.rm = TRUE), mean = function(x, ...) mean(x, ..., na.rm = TRUE), median = function(x, ...) median(x, ..., na.rm = TRUE) ) 2. There seems to be confusion about what currying means. The Wikipedia page http://en.wikipedia.org/wiki/Currying indicates that the function Curry() defined above is really doing partial function application, not currying. I'm in no position to judge whether Byron got it right or Wikipedia did, but this suggests to me that the name Curry is inappropriate, since at least some people who know what currying is would not guess that it does what it does. I'm not completely sure that discussion is canonical: wikipedia citing a blog post does not a precedent make. I agree the distinction is sensible, but I think the partial function application sense of currying is standard enough that it would cause much confusion. We are not claiming that R has low-level currying, we're creating a function to simulate a useful property of currying. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
My suggestion was to mimic *nix systems: put the executable binaries in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Why isn't the default bin path for R under *nix something like /usr/bin/R-2.13.0/? If the users want to install multiple versions, they still have the choice to install them elsewhere. I'm not denying the possible necessity of having multiple versions in a system. In my opinion, the default values should be set according to probabilities: is it more likely for a user to use multiple versions or a single version of R? Of course, all of you are developers and the former probability might be higher, but I don't think many users will run the script A with R 2.12.1 and script B with R 2.13.0. The most typical situation I have seen is, (Windows) people install R and will forget to update it forever. I often have to urge our IT admin to update R in our department from a version released long long ago. You may argue my samples are not representative. Anyway, I can accept the default version string if nobody agrees with me. I do use Emacs every day. It's nice, I totally agree. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, May 4, 2011 at 2:02 AM, Martin Maechler maech...@stat.math.ethz.ch wrote: Note to Yihui Xie: I agree 100% with the other R core members (Duncan, Simon, Thomas) who already explained why it is *GOOD* to install R in version-named directories by default. BTW: If you use ESS (Emacs Speaks Statistics) on Windows, it now automatically(*) finds all versions of R (* well, less generally, probably than Gabor's batch files; IIRC, we assume that the R versions were installed in the default place), and provides them, both the 32bit and 64bit versions, in the ESS menu, or via M-x R- [Tab completion] Very nice, very useful in my eyes. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?
On 5/3/11 2:39 PM, Hadley Wickham wrote: Part of the motivation for the reference classes was to bring a general OOP view to R. One can start from some essential concepts of objects and their properties, inheritance and class definition, as have evolved over a very long time. Next, there is a fundamental choice of paradigm between encapsulated OOP as the rest of the world knows it, and functional OOP as practiced by S and R, and a few other languages. While the two paradigms are quite different, there is no need to view them as opposed. They provide different advantages and tend to suit different goals--very roughly, functional object creation and reproducible results versus persistent objects whose properties one would like to have evolve over time using their encapsulated methods. My biggest worry with the introduction of reference classes is that many people will just stick to the style of OOP that they're familiar with, and not bother to learn the strengths of the generic function approach. Well, that says that presenting the choices well is important. Agreed. But the alternative is (and has been) for people from the other OOP background to hack something using the functional S4/S3 paradigm and then complain when it doesn't behave as expected. Not really preferable. As these remarks may suggest, I'm trying to write up this perspective in some detail. To be continued Are you familiar with Concepts, Techniques, and Models of Computer Programming by van Roy and Haridi? That's what really helped me to understand the strengths and weaknesses of the various styles of programming. Thanks, I wasn't. Yes, interesting similar distinction between functional and type decomposition. An important associated aspect for us is the distinction between reference objects and ordinary R objects, not AFAICS conveyed by their more abstract treatment. John Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
Or maybe
Curry - function(FUN, ...) {
args - match.call(expand.dots = FALSE)$...
args$... - as.name(...)
curry_call - as.call(c(list(as.name(FUN)), args))
eval(bquote(function(...) .(curry_call)))
}
Or one more approach:
Curry - function(FUN, ...) {
args - match.call(expand.dots = FALSE)$...
args$... - as.name(...)
curry_call - as.call(c(list(as.name(FUN)), args))
eval(call(function, as.pairlist(alist(... = )), curry_call))
}
I'm not sure if there's a canonical way of programmatically creating functions.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: Accessing methods via [[...]], bug?
Are you familiar with Concepts, Techniques, and Models of Computer Programming by van Roy and Haridi? That's what really helped me to understand the strengths and weaknesses of the various styles of programming. Thanks, I wasn't. Yes, interesting similar distinction between functional and type decomposition. An important associated aspect for us is the distinction between reference objects and ordinary R objects, not AFAICS conveyed by their more abstract treatment. Another discussion I found useful was in SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3 I really like the metaphor of method dispatch as a table with types in the columns and operations in the rows - then you can think of generic functions oo as being row-based, and class based oo as column-based. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] General nil reference class object
Interesting idea.
One approach would be to test against the _environment_ of the prototype
object in the class definition. Since the initialize method for a
reference class must call new.env(), one knows that a real object from
the class has a different environment. Using that fact one could have
functions
nullObject(Class)
to get the null, and
isNullObject(x)
to test.
My feeling is that this approach is better for R than having one single
nil object, because nullObject(Class) would still be a valid object from
the class.
Something to mull over.
John
On 5/4/11 6:09 AM, Jon Clayden wrote:
Dear John and others,
I've been wondering about whether there's any way to indicate a nil
reference class object, which will represent no value, and be tested
for, but not fail the internal type checking. NULL is the obvious
choice (or seems so to me), but can only be used if an explicit class
union is created:
Foo- setRefClass(Foo)
Bar- setRefClass(Bar, fields=list(foo=Foo))
Bar$new(foo=NULL)
Error in as(value, Foo) :
no method or default for coercing NULL to Foo
setClassUnion(FooOrNull, c(Foo,NULL))
[1] FooOrNull
Bar- setRefClass(Bar, fields=list(foo=FooOrNull))
Bar$new(foo=NULL)
An object of class Bar
environment: 0x10392c4a0
is.null(Bar$new(foo=NULL)$foo)
[1] TRUE
Other languages allow things like MyClass object = null, and it
seems to me that it would be helpful to have a value which will always
give TRUE for is(object,AnyReferenceClassName), but will
specifically indicate a nil reference. One possible ad-hoc solution is
to define the empty object of a base class to be nil (see below),
but it seems like it would be better to have a value specifically
designed for this purpose.
nilObject- Foo$new()
is.nilObject- function (x) identical(x,nilObject)
Bar- setRefClass(Bar, fields=list(foo=Foo), methods=list(
+ initialize=function (foo=nilObject) { initFields(foo=foo) }))
is.nilObject(Bar$new()$foo)
[1] TRUE
Is there already something like this that I'm not aware of? If not,
would it be possible and generally desirable to create it?
All the best,
Jon
--
Jonathan D Clayden, PhD
Lecturer in Neuroimaging and Biophysics
Imaging and Biophysics Unit
UCL Institute of Child Health
30 Guilford Street
LONDON WC1N 1EH
United Kingdom
__
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] Reference Classes: (Was: Accessing methods via [[...]], bug?)
On 5/4/11 9:24 AM, Hadley Wickham wrote: Are you familiar with Concepts, Techniques, and Models of Computer Programming by van Roy and Haridi? That's what really helped me to understand the strengths and weaknesses of the various styles of programming. Thanks, I wasn't. Yes, interesting similar distinction between functional and type decomposition. An important associated aspect for us is the distinction between reference objects and ordinary R objects, not AFAICS conveyed by their more abstract treatment. Another discussion I found useful was in SICP: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-17.html#%_sec_2.4.3 I really like the metaphor of method dispatch as a table with types in the columns and operations in the rows - then you can think of generic functions oo as being row-based, and class based oo as column-based. Except that functional method dispatch with multiple dispatch is dispatched on a K-tple of classes if the generic function has K arguments in its signature. This is not a trivial distinction because it means that a method can depend on more than one class definition, so it's not just a matter of distributing the same information in different ways, but a fundamentally more complicated structure for functional OOP (for better and/or for worse). John Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
Byron Ellis-2 wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
...
I would like to see this as well---it is one of the functional programming
constructs I really miss in R after playing with languages like Haskell.
Currently, the only Curry implementation I know of is in the roxygen package
which is kind of a weird dependency to install just for this one function.
-Charlie
-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context:
http://r.789695.n4.nabble.com/Curry-proposed-new-functional-programming-er-function-tp917654p3496226.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Curry: proposed new functional programming, er, function.
On Wed, May 4, 2011 at 1:11 PM, Sharpie ch...@sharpsteen.net wrote: Currently, the only Curry implementation I know of is in the roxygen package which is kind of a weird dependency to install just for this one function. Not entirely comparable but the proto package supports currying of proto arguments. For example, p$ls returns an instantiatedProtoMethod which is an S3 subclass of function that is like the original method but with the first argument filled in: library(proto) p - proto(x = 1) p$ls() [1] x -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tkrplot not working in R 2.13.0
It looks like the spaces in the path is the problem, when I run the line below with shQuote then everything starts working and all is right with the world again. Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, May 04, 2011 10:35 AM To: Greg Snow Cc: R Devel List Subject: Re: [Rd] tkrplot not working in R 2.13.0 What example are you trying? The code in ?trkplot works for me. However, it looks to me like that piece of advice in the rw-FAQ about no spaces in your path has come back to bite you (I of course do not have such spaces). I think this should be .Tcl(paste(load, shQuote(file), Rplot)) or some such. On Wed, 4 May 2011, Greg Snow wrote: The tkrplot package is not working in version 2.13.0 for windows. I contacted the maintainer who unfortunately does not have easy access to a windows computer and says that it is working on the other platforms. I traced the problem down to the line in the .First.lib function: .Tcl(paste(load, file, Rplot)) With file being C:/Program Files/R/R- 2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system. I did check that the file exists and it can even be loaded using dyn.load, but when running the .Tcl command by hand it produces the following error: Error in structure(.External(dotTcl, ..., PACKAGE = tcltk), class = tclObj) : [tcl] could not find interpreter Rplot. It works in previous versions of R, so I am guessing that this is due to some change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the new R, or possibly something else. Does anyone else have any insights? sessionInfo() R version 2.13.0 (2011-04-13) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] tcltk stats graphics grDevices utils datasets methods [8] base other attached packages: [1] TeachingDemos_2.7 tkrplot_0.0-19 loaded via a namespace (and not attached): [1] tools_2.13.0 Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] tkrplot not working in R 2.13.0
On May 4, 2011, at 19:26 , Greg Snow wrote: It looks like the spaces in the path is the problem, when I run the line below with shQuote then everything starts working and all is right with the world again. Just for fun, see if it also works with tcl(load, file, Rplot) (.Tcl(paste()) is just *so* turn of the millennium, and particularly vulnerable to quoting hell effects.) Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, May 04, 2011 10:35 AM To: Greg Snow Cc: R Devel List Subject: Re: [Rd] tkrplot not working in R 2.13.0 What example are you trying? The code in ?trkplot works for me. However, it looks to me like that piece of advice in the rw-FAQ about no spaces in your path has come back to bite you (I of course do not have such spaces). I think this should be .Tcl(paste(load, shQuote(file), Rplot)) or some such. On Wed, 4 May 2011, Greg Snow wrote: The tkrplot package is not working in version 2.13.0 for windows. I contacted the maintainer who unfortunately does not have easy access to a windows computer and says that it is working on the other platforms. I traced the problem down to the line in the .First.lib function: .Tcl(paste(load, file, Rplot)) With file being C:/Program Files/R/R- 2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system. I did check that the file exists and it can even be loaded using dyn.load, but when running the .Tcl command by hand it produces the following error: Error in structure(.External(dotTcl, ..., PACKAGE = tcltk), class = tclObj) : [tcl] could not find interpreter Rplot. It works in previous versions of R, so I am guessing that this is due to some change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the new R, or possibly something else. Does anyone else have any insights? sessionInfo() R version 2.13.0 (2011-04-13) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] tcltk stats graphics grDevices utils datasets methods [8] base other attached packages: [1] TeachingDemos_2.7 tkrplot_0.0-19 loaded via a namespace (and not attached): [1] tools_2.13.0 Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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 -- Peter Dalgaard 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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
On May 4, 2011, at 12:00 PM, Yihui Xie wrote: My suggestion was to mimic *nix systems: put the executable binaries in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Except that there is not such thing on Windows! The closest to that is the system folder which is off limits for applications. Why isn't the default bin path for R under *nix something like /usr/bin/R-2.13.0/? It is on some unices (and most system-wide installations in practice) - but that's beside the point. Unix has a well-defined FHS so regardless where you install R you can always put a symlink into /usr/bin or /usr/local/bin. Windows has no such conventions so Gabor's solution is pretty much what you claim to want (and note that in unix you're exactly running a batch script with its rhome embedded to start R!). Even on unix you don't mess with PATH to select the R version to use. If the users want to install multiple versions, they still have the choice to install them elsewhere. I'm not denying the possible necessity of having multiple versions in a system. In my opinion, the default values should be set according to probabilities: is it more likely for a user to use multiple versions or a single version of R? Of course, all of you are developers and the former probability might be higher, but I don't think many users will run the script A with R 2.12.1 and script B with R 2.13.0. The most typical situation I have seen is, (Windows) people install R and will forget to update it forever. I often have to urge our IT admin to update R in our department from a version released long long ago. You may argue my samples are not representative. Anyway, I can accept the default version string if nobody agrees with me. Cheers, S I do use Emacs every day. It's nice, I totally agree. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, May 4, 2011 at 2:02 AM, Martin Maechler maech...@stat.math.ethz.ch wrote: Note to Yihui Xie: I agree 100% with the other R core members (Duncan, Simon, Thomas) who already explained why it is *GOOD* to install R in version-named directories by default. BTW: If you use ESS (Emacs Speaks Statistics) on Windows, it now automatically(*) finds all versions of R (* well, less generally, probably than Gabor's batch files; IIRC, we assume that the R versions were installed in the default place), and provides them, both the 32bit and 64bit versions, in the ESS menu, or via M-x R- [Tab completion] Very nice, very useful in my eyes. 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] tkrplot not working in R 2.13.0
That works as well, I will suggest it to Luke for the package to use. Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: peter dalgaard [mailto:pda...@gmail.com] Sent: Wednesday, May 04, 2011 11:43 AM To: Greg Snow Cc: Prof Brian Ripley; R Devel List Subject: Re: [Rd] tkrplot not working in R 2.13.0 On May 4, 2011, at 19:26 , Greg Snow wrote: It looks like the spaces in the path is the problem, when I run the line below with shQuote then everything starts working and all is right with the world again. Just for fun, see if it also works with tcl(load, file, Rplot) (.Tcl(paste()) is just *so* turn of the millennium, and particularly vulnerable to quoting hell effects.) Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -Original Message- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, May 04, 2011 10:35 AM To: Greg Snow Cc: R Devel List Subject: Re: [Rd] tkrplot not working in R 2.13.0 What example are you trying? The code in ?trkplot works for me. However, it looks to me like that piece of advice in the rw-FAQ about no spaces in your path has come back to bite you (I of course do not have such spaces). I think this should be .Tcl(paste(load, shQuote(file), Rplot)) or some such. On Wed, 4 May 2011, Greg Snow wrote: The tkrplot package is not working in version 2.13.0 for windows. I contacted the maintainer who unfortunately does not have easy access to a windows computer and says that it is working on the other platforms. I traced the problem down to the line in the .First.lib function: .Tcl(paste(load, file, Rplot)) With file being C:/Program Files/R/R- 2.13.0/library/tkrplot/libs/i386/tkrplot.dll on my system. I did check that the file exists and it can even be loaded using dyn.load, but when running the .Tcl command by hand it produces the following error: Error in structure(.External(dotTcl, ..., PACKAGE = tcltk), class = tclObj) : [tcl] could not find interpreter Rplot. It works in previous versions of R, so I am guessing that this is due to some change in R, or the tcl with R 2.13.0, or how tkrplot was compiled under the new R, or possibly something else. Does anyone else have any insights? sessionInfo() R version 2.13.0 (2011-04-13) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] tcltk stats graphics grDevices utils datasets methods [8] base other attached packages: [1] TeachingDemos_2.7 tkrplot_0.0-19 loaded via a namespace (and not attached): [1] tools_2.13.0 Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk 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 -- Peter Dalgaard 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] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
There are plenty of good reasons for non-developers to run different versions of R. For instance, I care a lot about reproducibility. With every new release of R, lots of things change. With every new release of the packages I use, lots of things change. All of my analyses are performed using Sweave, and every report includes a call to sessionInfo so that the versions are recorded in the final report. If I have to go back and tweak something in a report (say, to regenerate a figure in a format more suitable for publication), I do not want the rest of the analysis to change. So I have to run the correct (possibly older) version of R. All of the stat analysts that we train follow the same practice. As a result, I am strongly opposed to an installation that automatically mucks with the path to R. Kevin On 5/4/2011 11:00 AM, Yihui Xie wrote: My suggestion was to mimic *nix systems: put the executable binaries in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Why isn't the default bin path for R under *nix something like /usr/bin/R-2.13.0/? If the users want to install multiple versions, they still have the choice to install them elsewhere. I'm not denying the possible necessity of having multiple versions in a system. In my opinion, the default values should be set according to probabilities: is it more likely for a user to use multiple versions or a single version of R? Of course, all of you are developers and the former probability might be higher, but I don't think many users will run the script A with R 2.12.1 and script B with R 2.13.0. The most typical situation I have seen is, (Windows) people install R and will forget to update it forever. I often have to urge our IT admin to update R in our department from a version released long long ago. You may argue my samples are not representative. Anyway, I can accept the default version string if nobody agrees with me. I do use Emacs every day. It's nice, I totally agree. Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in .Fortran Call
Thanks a lot. I will try the recommended changes. Ravi -- View this message in context: http://r.789695.n4.nabble.com/Error-in-Fortran-Call-tp3495319p3495777.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check and Suggests Packages
On 11-05-03 12:43 AM, Martin Maechler wrote:
Hervé Pagèshpa...@fhcrc.org
on Mon, 02 May 2011 11:55:08 -0700 writes:
Hi, On 11-04-28 07:00 PM, Dario Strbenac wrote:
Hello,
In my description file, I have an example data package in
Suggests: that I've deleted from my library to test what
the user who doesn't have it will experience.
However, R CMD check won't even pass my package :
* checking package dependencies ... ERROR
Package required but not available: RepitoolsExamples
confusing!
Wouldn't a message like
Package required for full checking but not available:
RepitoolsExamples
be more appropriate and avoid a confusion that we've seen
for a very long time now?
Sure. But such messages are already produced in current
versions of R,
Not for me. For example, picking up a CRAN package with a
Suggests field:
http://cran.fhcrc.org/web/packages/AICcmodavg/index.html
Then, after downloading the source tarball:
hpages@latitude:~/Downloads$ R-2.13 CMD check AICcmodavg_1.15.tar.gz
* using log directory ‘/home/hpages/Downloads/AICcmodavg.Rcheck’
* using R version 2.13.0 (2011-04-13)
* using platform: x86_64-unknown-linux-gnu (64-bit)
* using session charset: UTF-8
* checking for file ‘AICcmodavg/DESCRIPTION’ ... OK
* checking extension type ... Package
* this is package ‘AICcmodavg’ version ‘1.15’
* checking package dependencies ... ERROR
Package required but not available: lme4
See the information on DESCRIPTION files in the chapter 'Creating R
packages' of the 'Writing R Extensions' manual.
Cheers,
H.
.. at least they are there in the package checking
source, see
format.check_package_depends() in
src/library/tools/R/QC.R
which has e.g.,
if(length(bad- x$suggests_but_not_installed) 1L) {
c(gettext(Packages suggested but not available for checking:),
and similar for 'Enhances' in lieu of 'Suggests'.
If Dario really uses R 2.13.0 (or newer),
and he gets the above error message for a package that is not
required but only suggested,
I think we'd need a clear, ideally simple,
reproducible example, here.
Martin
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
Yihui Xie-2 wrote: Hi, I guess this issue must have been brought forward long time ago, but I still hope you can consider under Windows (during installation): 1. put R's bin path in the PATH variable of the system so that we can use the commands R and Rscript more easily; On one hand it certainly would be nice to have this as an option similar to what the RTools installer does. For the 32/64 bit decision, perhaps RHOME/bin could be placed on the PATH and bin/R.exe turned into a bin/R.bat that calls bin/i386/R.exe, bin/x64/R.exe depending on the Windows architecture. On the other hand, the grizzled developer in me is saying this is a teaching moment. If someone is using a programming language they should know what an environment variable is and how to set it. Admittingly, setting environment variables is a PITA on Windows compared to UNIX. Here's a great freeware tool I have found that makes it so much easier: http://www.rapidee.com Another issue is that many Windows machines are locked down in such a way that environment variables cannot be set permanently. To deal with this, I carry a USB stick that has R installed on it and a batch script that `setx`es environment variables for me. Combined with an `autorun.inf` script, this basically lets me plug my USB stick into a Windows machine and get to work without worrying about how careful the sysadmin was when they set up the tools I like to use (or if they even bothered to include the tools I like to use). A good video tutorial for setting up autorun.inf from Tinkernut.com: http://www.youtube.com/watch?v=lFlgddjOPpw Some of the things in that video are outdated and the overall goal is to show how they could be used for nefarious purposes, but the part about converting a `.bat` script to a `.exe` binary and setting up an autorun.inf to execute the result is solid. Combine with MikTeX Portable and you should be able to Sweave from anywhere. Yihui Xie-2 wrote: 2. remove the version string like R-2.13.0 in the default installation directory, e.g. only use a directory like C:/Program Files/R/ instead of C:/Program Files/R/R-2.13.0/; I know many people just follow the default setting when installing R, and this version string will often lead to many (unnecessary) copies of R in the system and brings difficulty to the first issue (several possible bin directories); I'm aware of some existing efforts in overcoming the difficulty of calling R under Windows like the R batch files project (http://code.google.com/p/batchfiles/), but I believe this is better to be solved in R directly. As a package developer I rather like this---I can have multiple versions of R installed and easily set up my testsuite such that it loops through each one and executes the tests. -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/Wishlist-write-R-s-bin-path-to-the-PATH-variable-and-remove-the-version-string-in-the-installation-ds-tp3493922p3496533.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reference Classes: replacing '.self' with an .Rda image of '.self' from within a method? (was replacing '.self' with an .Rda image of '.self' from within a method?)
Sorry guys,
but I chose a really stupid name before (no reference classes).
Hope it's okay to re-post.
Cheers,
Janko
ORIGINAL MESSAGE
Dear list,
Is it possible to update or reassign '.self' with an image of '.self'
(e.g. a locally stored .Rda file) from within a method?
I know that this might sound akward, but here's the use case:
1) Ref Class Definition
setRefClass(Class=Test,
fields=list(A=character, B=character),
methods=list(importImage=function(path){
variable - load(path)
expr - paste(assign(', variable, ',, variable, ,
envir=.self), sep=)
eval(parse(text=expr))
}
)
2) Initialize Method Definition
setMethod(
f=initialize,
signature=signature(.Object=Test),
definition=function(
.Object,
path=NULL
){
obj - callNextMethod(.Object)
if(!is.null(path){
obj$importImage(path=path)
}
return(obj)
}
3) Intended and Extended Use
Method 'importImage' was originally intended to read either an
object of name 'A' or 'B' from a respective path and overwrite the
respective fields in an obj of class 'Test'.
Now I wondered how I could reassign/update the object of class
'Test' itself by reading a respective .Rda image of an object of class
'Test' from within 'obj$importImage()'.
The way I've written 'importImage()', it did not work. Yet I wonder
if it's possible.
4) My Workaround (but I'm looking for something more elegantly)
In the class definition:
[...]
methods=list(importImage=function(path){
variable - load(path)
if(variable != .self){
expr - paste(assign(', variable, ',, variable, ,
envir=.self), sep=)
eval(parse(text=expr))
return(TRUE)
} else {
return(.self)
}
})
[...]
In the initialize method:
setMethod(
f=initialize,
signature=signature(.Object=Test),
definition=function(
.Object,
path=NULL
){
obj - callNextMethod(.Object)
if(!is.null(path){
rslt - obj$importImage(path=path)
if(!is.logical(rslt)){
obj - rslt
}
}
return(obj)
}
Thanks for any comments,
Janko
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to create vignette.pdf for R-2.13.0?
Dear Simon, I did not complain about the R doing something wrong. I only wanted to know why, after all these years, R CMD check does suddenly no longer build the pdf-files of the vignettes. I also think that this is a legal question. Let me compare the times spent: 1, the official development cycle: - R CMD build: 5 minutes - R CMD INSTALL: 3 minutes - R CMD check: 6 minutes 2, my own development cycle: - manual tarring: 2 seconds - R CMD check:6 minutes This means spending 14 minutes vs 6 minutes. If I assume that in one evening I have to make 10 corrections this would mean 140 minutes vs 60 minutes, i.e. the official development cycle would take 1 hr and 20 min longer than my own development cycle. This is time I do not have. Best regards Christian On 5/4/11 12:13 AM, Simon Urbanek wrote: On May 3, 2011, at 5:15 PM, cstrato wrote: No, I simply do tar czf xps_1.13.1.tar.gz xps. Well, that's your problem then, not R's. Source packages are created using R CMD build, not by manual tarring (you can do the latter if you know what you're doing, but then you can't complain about the R doing something wrong). Cheers, S On 5/3/11 11:11 PM, Simon Urbanek wrote: On May 3, 2011, at 4:48 PM, cstratocstr...@aon.at wrote: Dear Uwe, Thank you, however since I use R CMD INSTALL xps.tar.gz my source code is not polluted. But then you already used build to create the tar ball so the vignette has been built. So what is your point? Cheers, S Furthermore, I forgot to mention that finally I upload the source code only to the BioC svn repository. The rest is done by the BioC servers, including building the pdf-files for the vignettes. Best regards Christian On 5/3/11 10:13 PM, Uwe Ligges wrote: On 03.05.2011 21:14, cstrato wrote: Dear Uwe, This is my development cycle: First, I run R CMD check until there are no more warnings/errors. Since years it was very convenient that R CMD check builds the pdf-files of the vignettes, too, since this allowed me to correct errors in the manual files and the vignette files at the same time! Afterwards I run R CMD INSTALL to install my package and do more tests until everything works. As you see I do not use R CMD build, since every run takes about 5 minutes, it overwrites my zipped source code, and I would need to unzip it to get access to the vignette pdf-files. Then this is the main problem here. The *recommended* development cycle from the manuals is to run 1. R CMD build in order to get a valid source tarball and clean the sources 2. R CMD INSTALL to check if your package can be installed 3. R CMD check in order to finally check your package Running R CMD INSTALL on your source directory may pollute it, hence this is not recommended at all. Best, UWe Best regards Christian On 5/3/11 1:07 PM, Uwe Ligges wrote: On 02.05.2011 21:24, cstrato wrote: Dear Prof. Ripley, Thank you for your confirmation and explanation, I understand the reason for cleaning things up to save memory. However, it was very convenient to have this feature in earlier versions of R. It would be really helpful to have an additional option to R CMD check, e.g. --no-clean-vignettes. FYI, I did not claim ..create the vignettes *inpkginst/doc*, instead my words were: One interesting observation is that xps.Rcheck from R-2.12.2 contains the subdirectory inst/doc with the vignettes while xps.Rcheck from R-2.13.0 does not contain inst. But you do not need it. I do not know how often I have to mention that vignettes are produced by R CMD build! They are already build when running R CMD check. And please do not tell us about tzhe PDF version oif manuals which are *unrelated* to vignettes, because they are not built in advance and need to be checked, since they should be produced at user level while vignettes are built at developer level already. Uwe Ligges Best regards Christian _._._._._._._._._._._._._._._._._._ C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a e.m.a.i.l: cstrato at aon.at _._._._._._._._._._._._._._._._._._ On 5/2/11 7:08 AM, Prof Brian Ripley wrote: On Sun, 1 May 2011, Duncan Murdoch wrote: On 11-05-01 4:10 PM, cstrato wrote: Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates xps_1.13.1.tar.gz which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Probably the answer is simply because it doesn't. For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has
Re: [Rd] tkrplot not working in R 2.13.0
Thanks -- new version on its way to CRAN. luke On Wed, 4 May 2011, Greg Snow wrote: That works as well, I will suggest it to Luke for the package to use. Thanks, -- Luke Tierney 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: l...@stat.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] Curry: proposed new functional programming, er, function.
Thanks, Hadley. This (i.e., different ways to prepare curry) is quite instructive to me. Best, Ravi. --- Ravi Varadhan, Ph.D. Assistant Professor, Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins University Ph. (410) 502-2619 email: rvarad...@jhmi.edu -Original Message- From: h.wick...@gmail.com [mailto:h.wick...@gmail.com] On Behalf Of Hadley Wickham Sent: Wednesday, May 04, 2011 12:01 PM To: Duncan Murdoch Cc: Ravi Varadhan; Byron Ellis; R Development Mailing List Subject: Re: [Rd] Curry: proposed new functional programming, er, function. # Use of Curry adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2) Two objections: 1. I don't see how that is preferable to adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2) It's less typing? A more helpful use is when you have a list of functions: funs - list( sum = sum, mean = mean, median = median ) with Curry function you can do : funs2 - lapply(funs, Curry, na.rm = TRUE) as opposed to funs2 - list( sum = function(x, ...) sum(x, ..., na.rm = TRUE), mean = function(x, ...) mean(x, ..., na.rm = TRUE), median = function(x, ...) median(x, ..., na.rm = TRUE) ) 2. There seems to be confusion about what currying means. The Wikipedia page http://en.wikipedia.org/wiki/Currying indicates that the function Curry() defined above is really doing partial function application, not currying. I'm in no position to judge whether Byron got it right or Wikipedia did, but this suggests to me that the name Curry is inappropriate, since at least some people who know what currying is would not guess that it does what it does. I'm not completely sure that discussion is canonical: wikipedia citing a blog post does not a precedent make. I agree the distinction is sensible, but I think the partial function application sense of currying is standard enough that it would cause much confusion. We are not claiming that R has low-level currying, we're creating a function to simulate a useful property of currying. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reference Classes: replacing '.self' with an .Rda image of '.self' from within a method? (was replacing '.self' with an .Rda image of '.self' from within a method?)
It makes no sense to replace the .self field: that field is initialized
to be a reference to the object. If you change it, it's no longer that
reference.
There are many things wrong with your example, so it's better to take a
very simple version:
mkTest - setRefClass(test,fields = list(a = numeric))
x - mkTest$new(a=1:10)
Now suppose we replace the .self field with another one:
y - mkTest$new(a = 11:20)
x$.self - y$.self
At this point x is messed up and does not correspond to the .self field:
x$a
[1] 1 2 3 4 5 6 7 8 9 10
x$.self$a
[1] 11 12 13 14 15 16 17 18 19 20
The same problem results no matter how you change the field. The only
difference with a method is that you do get a warning message.
pseudoSelf - as.environment(list(a = 5))
x$.self - pseudoSelf
x$a
[1] 1 2 3 4 5 6 7 8 9 10
x$.self$a
[1] 5
mkTest$methods(screwup = function(newSelf) .self - newSelf)
Warning message:
In .checkFieldsInMethod(def, fieldNames, allMethods) :
Non-local assignment to non-field names (possibly misspelled?)
.self - newSelf
( in method screwup for class test)
x - mkTest$new(a=1:10)
x$screwup(pseudoSelf)
x$a
[1] 1 2 3 4 5 6 7 8 9 10
x$.self$a
[1] 5
We need to make the .self field read-only.
On 5/4/11 12:39 PM, Janko Thyson wrote:
Sorry guys,
but I chose a really stupid name before (no reference classes).
Hope it's okay to re-post.
Cheers,
Janko
ORIGINAL MESSAGE
Dear list,
Is it possible to update or reassign '.self' with an image of '.self'
(e.g. a locally stored .Rda file) from within a method?
I know that this might sound akward, but here's the use case:
1) Ref Class Definition
setRefClass(Class=Test,
fields=list(A=character, B=character),
methods=list(importImage=function(path){
variable - load(path)
expr - paste(assign(', variable, ',, variable, , envir=.self),
sep=)
eval(parse(text=expr))
}
)
2) Initialize Method Definition
setMethod(
f=initialize,
signature=signature(.Object=Test),
definition=function(
.Object,
path=NULL
){
obj - callNextMethod(.Object)
if(!is.null(path){
obj$importImage(path=path)
}
return(obj)
}
3) Intended and Extended Use
Method 'importImage' was originally intended to read either an object of
name 'A' or 'B' from a respective path and overwrite the respective
fields in an obj of class 'Test'.
Now I wondered how I could reassign/update the object of class 'Test'
itself by reading a respective .Rda image of an object of class 'Test'
from within 'obj$importImage()'.
The way I've written 'importImage()', it did not work. Yet I wonder if
it's possible.
4) My Workaround (but I'm looking for something more elegantly)
In the class definition:
[...]
methods=list(importImage=function(path){
variable - load(path)
if(variable != .self){
expr - paste(assign(', variable, ',, variable, , envir=.self),
sep=)
eval(parse(text=expr))
return(TRUE)
} else {
return(.self)
}
})
[...]
In the initialize method:
setMethod(
f=initialize,
signature=signature(.Object=Test),
definition=function(
.Object,
path=NULL
){
obj - callNextMethod(.Object)
if(!is.null(path){
rslt - obj$importImage(path=path)
if(!is.logical(rslt)){
obj - rslt
}
}
return(obj)
}
Thanks for any comments,
Janko
__
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] Curry: proposed new functional programming, er, function.
Hi,
On 5 May 2011 02:56, Duncan Murdoch murdoch.dun...@gmail.com wrote:
On 04/05/2011 10:40 AM, Ravi Varadhan wrote:
I too would like this (being an Indian!).
Here is an example that came up just yesterday with regards to solving a
quadrature problem using the cubature package. The adaptIntegrate
function does not allow additional arguments via ...
Uwe suggested a work around, but `Curry' would solve it nicely (and it
also tastes better!):
Curry = function(FUN,...) {
.orig = list(...)
function(...) do.call(FUN,c(.orig, list(...)))
}
require(cubature)
f- function(x, a) cos(2*pi*x*a) # a simple test function
# this works
a- 0.2
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2)
# but this doesn't work
rm(a)
adaptIntegrate(function(x, argA=a) f(x, a=argA), lower=0, upper=2, a=0.2)
# Use of Curry
adaptIntegrate(Curry(f, a=0.2), lower=0, upper=2)
Two objections:
1. I don't see how that is preferable to
adaptIntegrate(function(x) f(x, a=0.2), lower=0, upper=2)
In this particular case I don't think it is. The reason I proposed it
yesterday for the cubature example was that in some cases it can make
the code more concise and clearer in my opinion. This is the case when
you override a considerable number of arguments in a function.
Consider this,
read.table2 = Curry(read.table, header = TRUE, na.strings = ,
colClasses = numeric, nrows = 23)
vs
read.table2 = function(..., header = TRUE, na.strings = ,
colClasses = numeric, nrows = 23)
{
read.table(header = header, na.strings = na.strings,
colClasses = colClasses, nrows = nrows, ...)
}
Whether or not this should be called curry, I have no idea. In any
case it seems like a useful function to have in a base package,
regardless of its implementation details.
baptiste
2. There seems to be confusion about what currying means. The Wikipedia
page http://en.wikipedia.org/wiki/Currying indicates that the function
Curry() defined above is really doing partial function application, not
currying. I'm in no position to judge whether Byron got it right or
Wikipedia did, but this suggests to me that the name Curry is
inappropriate, since at least some people who know what currying is would
not guess that it does what it does.
Duncan Murdoch
Best,
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns
Hopkins University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Hadley Wickham
Sent: Wednesday, May 04, 2011 10:29 AM
To: Byron Ellis
Cc: R Development Mailing List
Subject: Re: [Rd] Curry: proposed new functional programming, er,
function.
I thought I might bring this up again - it now seems like Curry would
be a natural fit with Reduce, Filter, Find, Map, Negate and Position.
Any chance we might see this in a future version of R?
Hadley
On Thu, Nov 1, 2007 at 2:00 PM, Byron Ellisbyron.el...@gmail.com wrote:
Hi all (especially R-core) I suppose,
With the introduction of the new functional programming functions into
base I thought I'd ask for a Curry() function. I use a simple one that
looks this:
Curry = function(FUN,...) { .orig = list(...);function(...)
do.call(FUN,c(.orig,list(...))) }
This comes in really handy when using say, heatmap():
heatmap(mydata,hclustfun=Curry(hclust,method=average))
or other functions where there are ... arguments, but it's not clear
where they should end up.
--
Byron Ellis (byron.el...@gmail.com)
Oook -- The Librarian
__
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
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
First, you are still able to install multiple versions of R to any places that you want -- I was suggesting a default place to install R under Windows. If you remember the process of installing R under Windows, there is a step in which you can choose where to install R. Second, to modify the PATH variable won't affect reproducibility. It seems people have got a wrong impression that after the PATH variable is modified, we are forced to use the single version of R under the PATH. You are still free to use any versions of R. The only effect is that if you run R as a command, it will be the version which is under the PATH. Do you run your Sweave documents via R CMD Sweave? If not, this will not affect you. If people are really uncomfortable with the PATH variable being modified, we can make this *optional* just like what Rtools does. If we are so worried about all these kinds of problems, do we need to worry about Rtools as well? Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, May 4, 2011 at 1:33 PM, Kevin R. Coombes kevin.r.coom...@gmail.com wrote: There are plenty of good reasons for non-developers to run different versions of R. For instance, I care a lot about reproducibility. With every new release of R, lots of things change. With every new release of the packages I use, lots of things change. All of my analyses are performed using Sweave, and every report includes a call to sessionInfo so that the versions are recorded in the final report. If I have to go back and tweak something in a report (say, to regenerate a figure in a format more suitable for publication), I do not want the rest of the analysis to change. So I have to run the correct (possibly older) version of R. All of the stat analysts that we train follow the same practice. As a result, I am strongly opposed to an installation that automatically mucks with the path to R. Kevin On 5/4/2011 11:00 AM, Yihui Xie wrote: My suggestion was to mimic *nix systems: put the executable binaries in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Why isn't the default bin path for R under *nix something like /usr/bin/R-2.13.0/? If the users want to install multiple versions, they still have the choice to install them elsewhere. I'm not denying the possible necessity of having multiple versions in a system. In my opinion, the default values should be set according to probabilities: is it more likely for a user to use multiple versions or a single version of R? Of course, all of you are developers and the former probability might be higher, but I don't think many users will run the script A with R 2.12.1 and script B with R 2.13.0. The most typical situation I have seen is, (Windows) people install R and will forget to update it forever. I often have to urge our IT admin to update R in our department from a version released long long ago. You may argue my samples are not representative. Anyway, I can accept the default version string if nobody agrees with me. I do use Emacs every day. It's nice, I totally agree. Regards, Yihui -- Yihui Xiexieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: write R's bin path to the PATH variable and remove the version string in the installation dir under Windows
1. I know there is not such a thing; that why I said mimic and the same place (***/R/bin instead of ***/R/R-x.x.x/bin). 2. Yes, I never mess with the PATH variable under *nix, because R is installed to /usr/local/bin/ (or /usr/bin/) *by default*, which is already in the PATH variable. Otherwise extra efforts will be required to run R as a single letter R -- this is what I wish we were able to do under Windows. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Wed, May 4, 2011 at 12:55 PM, Simon Urbanek simon.urba...@r-project.org wrote: On May 4, 2011, at 12:00 PM, Yihui Xie wrote: My suggestion was to mimic *nix systems: put the executable binaries in the same place *by default* (e.g. /usr/bin/ or /usr/local/bin). Except that there is not such thing on Windows! The closest to that is the system folder which is off limits for applications. Why isn't the default bin path for R under *nix something like /usr/bin/R-2.13.0/? It is on some unices (and most system-wide installations in practice) - but that's beside the point. Unix has a well-defined FHS so regardless where you install R you can always put a symlink into /usr/bin or /usr/local/bin. Windows has no such conventions so Gabor's solution is pretty much what you claim to want (and note that in unix you're exactly running a batch script with its rhome embedded to start R!). Even on unix you don't mess with PATH to select the R version to use. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
