[Rd] "deparse" with "nlines" argument produces empty elements (PR#13299)
Full_Name: Kamil Bartoñ Version: 2.8.0 OS: windows xp Submission from: (NULL) (212.33.92.187) According to the "deparse" function documentation "nlines" is the *maximum* number of lines to produce. But, when "nlines" argument is supplied, it produces exactly nlines of result, and the result contains empty elements at the end. Example: > deparse(quote(foo(1,2,3)), width.cutoff = 20, nlines=7) [1] "foo(1, 2, 3)" "" "" "" "" "" "" This behavior affects e.g. output of warnings() where "..." is attached to every call rather than only the truncated ones. > warnings() Warning messages: 1: In plot.window(...) ... : "na.action" is not a graphical parameter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign("FALSE", TRUE)
On 18/11/2008, at 11:11 AM, Martin Maechler wrote:
Yes. I'd propose that R-core look into how to make assignment to a
reserved word an error.
That's good news. Thanks.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking for executable files ... WARNING
On Tue, Nov 18, 2008 at 1:31 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Mon, 17 Nov 2008, hadley wickham wrote: > >> In R 2.8. I get the following warning when checking my package: >> >> * checking for executable files ... WARNING >> Found the following executable file(s): >> .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 >> .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 >> .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 >> .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 >> ... (for about 300 lines) >> >> I've tried putting .git in my .Rbuildignore, but this doesn't help the >> problem. Any ideas? > > Does 'R CMD build' a tarball and then 'R CMD check' not solve this? > 'build' skips git files, and you only need to worry about executables in a > tarball you ship. Is this suggested best practice now? Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking for executable files ... WARNING
On Tue, 18 Nov 2008, hadley wickham wrote: On Tue, Nov 18, 2008 at 1:31 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: On Mon, 17 Nov 2008, hadley wickham wrote: In R 2.8. I get the following warning when checking my package: * checking for executable files ... WARNING Found the following executable file(s): .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 ... (for about 300 lines) I've tried putting .git in my .Rbuildignore, but this doesn't help the problem. Any ideas? Does 'R CMD build' a tarball and then 'R CMD check' not solve this? 'build' skips git files, and you only need to worry about executables in a tarball you ship. Is this suggested best practice now? Always was, AFAIK. Hadley -- http://had.co.nz/ -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checking for executable files ... WARNING
On Tue, Nov 18, 2008 at 7:00 AM, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Tue, 18 Nov 2008, hadley wickham wrote: > >> On Tue, Nov 18, 2008 at 1:31 AM, Prof Brian Ripley >> <[EMAIL PROTECTED]> wrote: >>> >>> On Mon, 17 Nov 2008, hadley wickham wrote: >>> In R 2.8. I get the following warning when checking my package: * checking for executable files ... WARNING Found the following executable file(s): .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 ... (for about 300 lines) I've tried putting .git in my .Rbuildignore, but this doesn't help the problem. Any ideas? >>> >>> Does 'R CMD build' a tarball and then 'R CMD check' not solve this? >>> 'build' skips git files, and you only need to worry about executables in >>> a >>> tarball you ship. >> >> Is this suggested best practice now? > > Always was, AFAIK. I might be useful to make this more explicit in "Writing R extensions". A sentence at the start of 1.3.1 "checking packages" would be helpful, as would removing this sentence from 1.3.2: "Run-time checks whether the package works correctly should be performed using R CMD check prior to invoking the build procedure." and strengthening the recommendation in this sentence: "It can be useful to run R CMD check --check-subdirs=yes on the built tarball as a final check on the contents." You didn't mention "--check-subdirs=yes" and I see from R CMD CHECK --help that yes is now the default, so perhaps that could be removed too. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign("FALSE", TRUE)
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
> on Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD> Martin Maechler wrote:
>> But in spite of all that I agree that I'd have liked
>> `FALSE` <- to signal an error about the fact
>> that it is a reserved word.
>>
RT> This is clearly not a very important issue, but it might
RT> bear some thinking about.
>>
>> Yes. I'd propose that R-core look into how to make
>> assignment to a reserved word an error.
PD> I disagree. In a sense, this is the point of having the
PD> backtick operator: allowing you to work with names that
PD> would otherwise be syntax errors (notice that such names
PD> are sometimes created outside your control, e.g. via
PD> column names in data frames). If you start disallowing
PD> some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise syntax
errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
{ S / S-plus does not either and gives a nice error message:
S> assign("FALSE", TRUE)
Problem: The name "FALSE" is reserved -- assignments to it are not allowed
}
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign("FALSE", TRUE)
Martin Maechler wrote:
>> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
>> on Tue, 18 Nov 2008 00:00:40 +0100 writes:
>
> PD> Martin Maechler wrote:
> >> But in spite of all that I agree that I'd have liked
> >> `FALSE` <- to signal an error about the fact
> >> that it is a reserved word.
> >>
> RT> This is clearly not a very important issue, but it might
> RT> bear some thinking about.
> >>
> >> Yes. I'd propose that R-core look into how to make
> >> assignment to a reserved word an error.
>
> PD> I disagree. In a sense, this is the point of having the
> PD> backtick operator: allowing you to work with names that
> PD> would otherwise be syntax errors (notice that such names
> PD> are sometimes created outside your control, e.g. via
> PD> column names in data frames). If you start disallowing
> PD> some of them again, well, that way lies madness!
>
> No, no. I'm not against allowing names that are otherwise syntax
> errors. They were always possible via assign().
> I just am convinced we should not allow reserved words.
Please unconvince yourself then... You are solving a problem that isn't
there: In R, you can assign to `FALSE` and access it as `FALSE`. You can
not access it as FALSE because that is a keyword and you cannot assign
to FALSE either.
> { S / S-plus does not either and gives a nice error message:
>
> S> assign("FALSE", TRUE)
> Problem: The name "FALSE" is reserved -- assignments to it are not allowed
> }
But FALSE is not a keyword in S. In R this would correspond to locking
down F and T.
There's another issue, namely that some keywords do have associated
functions; e.g., `if` exists as a variable, and walls do come tumbling
down if you redefine it (to a different function). However, that is a
completely different thing, more related to redefining "+".
(Incidentally, how hard would it be to ensure that such symbols were
always looked up in the base namespace?).
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign("FALSE", TRUE)
On Tue, 18 Nov 2008, Peter Dalgaard wrote:
Martin Maechler wrote:
"PD" == Peter Dalgaard <[EMAIL PROTECTED]>
on Tue, 18 Nov 2008 00:00:40 +0100 writes:
PD> Martin Maechler wrote:
>> But in spite of all that I agree that I'd have liked
>> `FALSE` <- to signal an error about the fact
>> that it is a reserved word.
>>
RT> This is clearly not a very important issue, but it might
RT> bear some thinking about.
>>
>> Yes. I'd propose that R-core look into how to make
>> assignment to a reserved word an error.
PD> I disagree. In a sense, this is the point of having the
PD> backtick operator: allowing you to work with names that
PD> would otherwise be syntax errors (notice that such names
PD> are sometimes created outside your control, e.g. via
PD> column names in data frames). If you start disallowing
PD> some of them again, well, that way lies madness!
No, no. I'm not against allowing names that are otherwise syntax
errors. They were always possible via assign().
I just am convinced we should not allow reserved words.
Please unconvince yourself then... You are solving a problem that isn't
there: In R, you can assign to `FALSE` and access it as `FALSE`. You can
not access it as FALSE because that is a keyword and you cannot assign
to FALSE either.
{ S / S-plus does not either and gives a nice error message:
S> assign("FALSE", TRUE)
Problem: The name "FALSE" is reserved -- assignments to it are not allowed
}
But FALSE is not a keyword in S. In R this would correspond to locking
down F and T.
I think both F and FALSE are 'keywords' in S, as that appears to say.
There's another issue, namely that some keywords do have associated
functions; e.g., `if` exists as a variable, and walls do come tumbling
down if you redefine it (to a different function). However, that is a
completely different thing, more related to redefining "+".
(Incidentally, how hard would it be to ensure that such symbols were
always looked up in the base namespace?).
You mean they are primitives, so 'variable' for some meaning such as
'object'? The obvious idea is for the parser to do the lookup, but then
the deparser would need to be altered. Otherwise the evaluator needs to
special-case them, with a slight performance hit.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13299) "deparse" with "nlines" argument produces empty elements
Although it does actually do what it is documented to do, producing the minimum necessary number of lines would be better, and I've altered R-patched to do so. Thank you for the report. Brian Ripley (who was in Bialowieza a couple of months ago). On Tue, 18 Nov 2008, [EMAIL PROTECTED] wrote: Full_Name: Kamil Bartoñ Version: 2.8.0 OS: windows xp Submission from: (NULL) (212.33.92.187) According to the "deparse" function documentation "nlines" is the *maximum* number of lines to produce. But, when "nlines" argument is supplied, it produces exactly nlines of result, and the result contains empty elements at the end. Example: deparse(quote(foo(1,2,3)), width.cutoff = 20, nlines=7) [1] "foo(1, 2, 3)" "" "" "" "" "" "" This behavior affects e.g. output of warnings() where "..." is attached to every call rather than only the truncated ones. warnings() Warning messages: 1: In plot.window(...) ... : "na.action" is not a graphical parameter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fwd: Fwd: SWIG with R and C++ STL
Thanks guys for all your kind heartedness.
Yeah, I got messed up with a lot of things in my previous program, like
missing the definition of one function and etc. I finally discovered a good
example on:
http://www.opensource.apple.com/darwinsource/Current/swig-4/swig/Examples/java/funcptr/index.html.
And I was able to make a workable example as following:
/* test.i */
%module test
%{
#include "test.h"
%}
%include "test.h"
%constant B (*F)( const A&)=f;
//let a=A(), b=B()
%template(ia) ex1; // from Doc, works
%template(jab) ex2; // jab(a,b) works
%template(kab) ex3; // kab(a,b,1) works
%template(lab) ex4; // lab(a,b,1,F) works
%template(fab) ex5; // fab(a,b,1,F) ultimate goal
/* test.h */
#include
using namespace std;
class A { };
class B { };
class E { };
B f( const A& ) { cout<<"This is a function map A to B"< E ex1(T a, T b) { cout<<"ex1, one parameter
template"< E ex2(T t, S s) { cout<<"ex2, two parameters
template"< E ex3(T t, S s, int k) {
cout<<"ex3, two parameters template plus an int argument"< E ex4(T t, S s, int k, fp gp) {
cout<<"ex4, two parameters template, an int argument and an func ptr
argument"< E ex5(C c, D& d, int n, D (*g)(const C&)) {
cout<<"ex5, two parameters template, an int argument and a template func
ptr argument"
Re: [Rd] Fwd: Fwd: SWIG with R and C++ STL
no all compilers support the export keyword.
just put the template in a .h or .hpp file and include it in your .cpp
file. that should be enough.
-Whit
On Tue, Nov 18, 2008 at 2:50 PM, charlie <[EMAIL PROTECTED]> wrote:
> Thanks guys for all your kind heartedness.
>
> Yeah, I got messed up with a lot of things in my previous program, like
> missing the definition of one function and etc. I finally discovered a good
> example on:
> http://www.opensource.apple.com/darwinsource/Current/swig-4/swig/Examples/java/funcptr/index.html.
> And I was able to make a workable example as following:
>
> /* test.i */
> %module test
> %{
> #include "test.h"
> %}
> %include "test.h"
>
> %constant B (*F)( const A&)=f;
> //let a=A(), b=B()
> %template(ia) ex1; // from Doc, works
> %template(jab) ex2; // jab(a,b) works
> %template(kab) ex3; // kab(a,b,1) works
> %template(lab) ex4; // lab(a,b,1,F) works
> %template(fab) ex5; // fab(a,b,1,F) ultimate goal
>
> /* test.h */
>
> #include
> using namespace std;
>
> class A { };
> class B { };
> class E { };
> B f( const A& ) { cout<<"This is a function map A to B"< B); };
> typedef B (*fp)( const A& );
>
> template E ex1(T a, T b) { cout<<"ex1, one parameter
> template"< // NOTE: simple template function
>
> template E ex2(T t, S s) { cout<<"ex2, two parameters
> template"< // NOTE: this extends the one above with two template parameters
>
> template E ex3(T t, S s, int k) {
> cout<<"ex3, two parameters template plus an int argument"< *(new E); }
> // NOTE: this extends the one above with additional integer argument
>
> template E ex4(T t, S s, int k, fp gp) {
> cout<<"ex4, two parameters template, an int argument and an func ptr
> argument"< A a=A(); B b=gp(a); return *(new E); }
> // NOTE: this extends the one above with one more function poiter argument
>
> template E ex5(C c, D& d, int n, D (*g)(const C&)) {
> cout<<"ex5, two parameters template, an int argument and a template func
> ptr argument"< g(c); return *(new E); }
> // NOTE: this temaplate function TF takes a template function poiter as
> argument, our ultimate goal
>
> And currently I got my program work now. But the ex. in 5.4.9 still seems
> not working. Anyway, so far good for me now. Maybe one last thing, currently
> I need to put the definition and declaration of a template function all in
> one file, otherwise I got undefined symbol error. How can I separate them
> into a .h and .cpp file? The 'export' keyword which suggested in TCPL seems
> do't work with gcc. Any comments?
>
> Thanks a bunch already!
>
> Charlie
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] anyone familiar with this error?
[EMAIL PROTECTED] R.packages]$ sudo R CMD INSTALL portfolio.construction
* Installing to library '/usr/local/lib64/R/library'
* Installing *source* package 'portfolio.construction' ...
** R
** preparing package for lazy loading
Loading required package: fts
Loading required package: quadprog
Loading required package: Rexcelpoi
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
/usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done
( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\",
.libPaths(; .getRequiredPackages();
tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" )
25002 Aborted (core dumped) | R_DEFAULT_PACKAGES=
LC_ALL=C "${R_EXE}" --vanilla --slave
ERROR: lazy loading failed for package 'portfolio.construction'
** Removing '/usr/local/lib64/R/library/portfolio.construction'
** Restoring previous '/usr/local/lib64/R/library/portfolio.construction'
[EMAIL PROTECTED] R.packages]$
I've tried a few things, but can't seem to track down the problem.
it's leaving core files in my package directory. (not in the .Rcheck
directory, directly in the package dir)
Thanks,
Whit
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R license: GPL v2 or v3?
For a project I am porting some of R's source code, and I want to
get the license for my project correct, but the top level COPYING file
for R's source states GPL v2, but when using:
> license()
(which also states GPL version 2) points me towards:
> RShowDoc('COPYING')
which states GPL v3. Which is correct?
Thanks for clarification (and the amazing amount of code!).
Gabriel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anyone familiar with this error?
Don't really know but you could see if the info in Avoiding R Bugs
section on the http:/r-proto.googlecode.com page applies, particularly
the first point on Lazy Loading.
On Tue, Nov 18, 2008 at 5:07 PM, Whit Armstrong
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] R.packages]$ sudo R CMD INSTALL portfolio.construction
> * Installing to library '/usr/local/lib64/R/library'
> * Installing *source* package 'portfolio.construction' ...
> ** R
> ** preparing package for lazy loading
> Loading required package: fts
> Loading required package: quadprog
> Loading required package: Rexcelpoi
> terminate called after throwing an instance of 'std::logic_error'
> what(): basic_string::_S_construct NULL not valid
> /usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done
> ( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\",
> .libPaths(; .getRequiredPackages();
> tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" )
> 25002 Aborted (core dumped) | R_DEFAULT_PACKAGES=
> LC_ALL=C "${R_EXE}" --vanilla --slave
> ERROR: lazy loading failed for package 'portfolio.construction'
> ** Removing '/usr/local/lib64/R/library/portfolio.construction'
> ** Restoring previous '/usr/local/lib64/R/library/portfolio.construction'
> [EMAIL PROTECTED] R.packages]$
>
>
> I've tried a few things, but can't seem to track down the problem.
>
> it's leaving core files in my package directory. (not in the .Rcheck
> directory, directly in the package dir)
>
> Thanks,
> Whit
>
> __
> 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] anyone familiar with this error?
There was a slash missing. It should be
http://r-proto.googlecode.com
On Tue, Nov 18, 2008 at 6:31 PM, Gabor Grothendieck
<[EMAIL PROTECTED]> wrote:
> Don't really know but you could see if the info in Avoiding R Bugs
> section on the http:/r-proto.googlecode.com page applies, particularly
> the first point on Lazy Loading.
>
> On Tue, Nov 18, 2008 at 5:07 PM, Whit Armstrong
> <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] R.packages]$ sudo R CMD INSTALL portfolio.construction
>> * Installing to library '/usr/local/lib64/R/library'
>> * Installing *source* package 'portfolio.construction' ...
>> ** R
>> ** preparing package for lazy loading
>> Loading required package: fts
>> Loading required package: quadprog
>> Loading required package: Rexcelpoi
>> terminate called after throwing an instance of 'std::logic_error'
>> what(): basic_string::_S_construct NULL not valid
>> /usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done
>> ( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\",
>> .libPaths(; .getRequiredPackages();
>> tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" )
>> 25002 Aborted (core dumped) | R_DEFAULT_PACKAGES=
>> LC_ALL=C "${R_EXE}" --vanilla --slave
>> ERROR: lazy loading failed for package 'portfolio.construction'
>> ** Removing '/usr/local/lib64/R/library/portfolio.construction'
>> ** Restoring previous '/usr/local/lib64/R/library/portfolio.construction'
>> [EMAIL PROTECTED] R.packages]$
>>
>>
>> I've tried a few things, but can't seem to track down the problem.
>>
>> it's leaving core files in my package directory. (not in the .Rcheck
>> directory, directly in the package dir)
>>
>> Thanks,
>> Whit
>>
>> __
>> 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] more efficient small subsets from moderate vectors?
This creates a named vector of length nx, then repeatedly draws a
single sample from it.
lkup <- function(nx, m=1L) {
tbl <- seq_len(nx)
names(tbl) <- as.character(tbl)
v <- sample(names(tbl), m, replace=TRUE)
system.time(for(k in v) tbl[k], gcFirst=TRUE)
}
There is an abrupt performance degredation at nx=1000
> lkup(1000)
user system elapsed
0.180 0.000 0.179
> lkup(1001)
user system elapsed
2.444 0.016 2.462
This is because of the heuristic at stringSubscript.c:424, which
switches from a 'naive' nx * ns algorithm (ns is the number of
elements to be extracted, ns = 1 above) to a hash-based strategy when
nx * ns > 1.
It seems like the 'naive' algorithm takes nx * ns time, whereas the
hash-based algorithm takes C(nx) + ns, where C(nx) is the cost of
creating the hash. Guessing that the cost of building the hash is
about linear in nx, the results above suggest a new heuristic for
switching at ns of about 15.
(I don't quite follow the last sentence of the comment above
stringSubscript, so perhaps I misunderstand entirely).
Martin
> sessionInfo()
R version 2.9.0 Under development (unstable) (2008-11-15 r46953)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] anyone familiar with this error?
On Tue, 18 Nov 2008, Whit Armstrong wrote:
[EMAIL PROTECTED] R.packages]$ sudo R CMD INSTALL portfolio.construction
* Installing to library '/usr/local/lib64/R/library'
* Installing *source* package 'portfolio.construction' ...
** R
** preparing package for lazy loading
Loading required package: fts
Loading required package: quadprog
Loading required package: Rexcelpoi
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
/usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done
( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\",
.libPaths(; .getRequiredPackages();
tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" )
25002 Aborted (core dumped) | R_DEFAULT_PACKAGES=
LC_ALL=C "${R_EXE}" --vanilla --slave
ERROR: lazy loading failed for package 'portfolio.construction'
** Removing '/usr/local/lib64/R/library/portfolio.construction'
** Restoring previous '/usr/local/lib64/R/library/portfolio.construction'
[EMAIL PROTECTED] R.packages]$
I've tried a few things, but can't seem to track down the problem.
it's leaving core files in my package directory. (not in the .Rcheck
directory, directly in the package dir)
Well, you did INSTALL, not 'check', so there is no .Rcheck directory.
The issue is that it cannot load your package, and it seems the error is
in C++ code in the package or a dependency. You've given use very little
to go on beyond that.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R license: GPL v2 or v3?
On Tue, 18 Nov 2008, Gabriel Gellner wrote:
For a project I am porting some of R's source code, and I want to
get the license for my project correct, but the top level COPYING file
for R's source states GPL v2, but when using:
> license()
(which also states GPL version 2) points me towards:
> RShowDoc('COPYING')
which states GPL v3. Which is correct?
It does not, at least in R 2.8.0 (and I am pretty sure in no version
of R). What exactly are you looking at?
Many files in R are licensed under GPL 2 or later, but not all. All
non-trivial source files should have a header giving the licence terms for
that file.
Thanks for clarification (and the amazing amount of code!).
Gabriel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] more efficient small subsets from moderate vectors?
Note that you are talking about very small times here.
Yes, it probably switches early for ns=1, but is that a common usage?
Do people really do lots of single lookups from long vectors -- if so they
deserve what they get, and it would be better to use a hashed environment.
(Indeed a strategy considered but not implemented was to attach a hash for
future use.)
On Tue, 18 Nov 2008, Martin Morgan wrote:
This creates a named vector of length nx, then repeatedly draws a
single sample from it.
lkup <- function(nx, m=1L) {
tbl <- seq_len(nx)
names(tbl) <- as.character(tbl)
v <- sample(names(tbl), m, replace=TRUE)
system.time(for(k in v) tbl[k], gcFirst=TRUE)
}
There is an abrupt performance degredation at nx=1000
lkup(1000)
user system elapsed
0.180 0.000 0.179
lkup(1001)
user system elapsed
2.444 0.016 2.462
This is because of the heuristic at stringSubscript.c:424, which
switches from a 'naive' nx * ns algorithm (ns is the number of
elements to be extracted, ns = 1 above) to a hash-based strategy when
nx * ns > 1.
It seems like the 'naive' algorithm takes nx * ns time, whereas the
hash-based algorithm takes C(nx) + ns, where C(nx) is the cost of
creating the hash. Guessing that the cost of building the hash is
about linear in nx, the results above suggest a new heuristic for
switching at ns of about 15.
(I don't quite follow the last sentence of the comment above
stringSubscript, so perhaps I misunderstand entirely).
Martin
sessionInfo()
R version 2.9.0 Under development (unstable) (2008-11-15 r46953)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M2 B169
Phone: (206) 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
