Re: [Rd] Defining a method in two packages
I think a simpler solution, which I have implemented in lme4 but not
yet released is to have
importFrom(nlme, ranef, fixef)
in the NAMESPACE file of packages that implement methods for those
generics (and, of course, add nlme to the Imports: specification in
the DESCRIPTION file). As nlme is a required package I don't think
this is too much of a burden.
On Tue, Mar 9, 2010 at 8:52 PM, Kevin Coombes wrote:
> Wouldn't it make sense to simply create a "ranef" package whose only role in
> the universe is to create the generic function that lme4, coxme, and anyone
> else who needs it could just import, without getting tons of additional and
> (depending on the application) irrelevant code?
>
> Best,
> Kevin
>
> Uwe Ligges wrote:
>>
>>
>> On 08.03.2010 17:16, Terry Therneau wrote:
>>>
>>> Brian& Uwe,
>>> Thanks for responding. Let me see if I can refine the query and move
>>> towards a solution.
>>>
From Uwe:
Of course, after loading lme4, you can still use the ranef from coxme:
coxme::ranef(fit)
>>>
>>> Of course, but I'm interested in other users (as well as myself) and
>>> prefer to avoid the 'secret handshake' form of a call.
>>>
In your own package, you could simply import the generic from coxme.
>>>
>>> I don't understand this.
>>
>> You could import the generic from the other package and define your won
>> methods for it in order to make dispatching work correctly.
>>
>>
>>
From Brian:
My solution would though be NOT to reuse a name that is already
established in another package (nlme has used it for many years).
The design problem is that generic foo() in package B might have
nothing to do with foo() in package A. When it does, we expect B ...
>>>
>>> I disagree completely. It is precisely because of nlme and lmer
>>> prominence that I want to reprise their methods: my users have a much
>>> better chance of remembering how to do things. If I followed this logic
>>> to its conclusion one should never define a print() method because it
>>> might conflict with the base definition.
>>> The consequence is that I am under obligation to NOT make my method
>>> something different than Doug's, if I want to satisfy the goal of user
>>> level consistency. Several aspects of coxme purposefully mimic lmer,
>>> even in cases (such as print.coxme) where his layout is not precisely
>>> what I would have chosen.
>>
>> Then please folow my suggestion and import the generic from the packages
>> mentioned above in your namespace. Then you could extend it by your own
>> methods wihtout having to define another generic of the same name and avoid
>> the conflicts.
>>
>>
>>> I really do not want to require lme4 just to pick up the methods
>>> definition. It's a huge package, and there is no code in common. Both
>>> packages work very hard to be efficient via sparse matrix methods, but
>>> the actual details are completely different due to the mathematical
>>> structure of our underlying likelihoods. Use of both in the same
>>> analysis would be rare, so my issue won't be common.
>>
>> Well, then things become complicated if not impossible.
>>
>>
The situation can be alleviated by making S3 methods visible. Thus if
coxme exported coxme:::ranef.coxme and lme4 had a default method
>>>
ranef<- function (object, ...) UseMethod("ranef")
>>>
>>> I have no objection to exporting my method. If a joint change to lme4
>>> and coxme is the best solution, I will take the discussion off line with
>>> Doug. Is this the best way forward?
>>
>> I think so.
>>
>> Best wishes,
>> uwe
>>
>>
>>>
>>> Terry
>>>
>>>
>>>
>>>
>>
>> __
>> 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] Problem with gsl package
Hi Martin,
Good news. I got things to work. I think my gsl installation was
corrupted. In any event, thanks for your help.
Best,
Matt
-Original Message-
From: Martin Becker [mailto:martin.bec...@mx.uni-saarland.de]
Sent: Sunday, February 28, 2010 6:45 PM
To: Hoptman, Matthew
Cc: r-devel@r-project.org
Subject: Re: [Rd] Problem with gsl package
Hi,
I think I had similar problems with gsl on a non-standard installation.
The following steps seemed to work (but are merely the results of
struggling around...)
1. Download and extract source code of R-package 'gsl'
2. Use gsl-config --libs to get the path to GSL's lib directory
(-L), use gsl-config --cflags to get the path to GSL's
include directory (-I)
3. Change Makevars in gsl/src:
- Add -L to PKG_LIBS
- Add (new) line: PKG_CPPFLAGS=-I
4. Install gsl via
LDFLAGS=-L;export
LDFLAGS;CPPFLAGS=-I;export CPPFLAGS;R CMD INSTALL gsl
Best,
Martin
Hoptman, Matthew wrote:
> Hi all,
> I am new to R and am writing after having contacted Robin Hankin, who
> maintains the R gsl wrapper.
>
>
>
> I am trying to use an AFNI (neuroimaging analysis) program that
depends
> on the R gsl package. When I try to use the script I wrote, I get an
> error that led me to suspect the gsl package was a culprit. When I do
> library("gsl") within R, I get:
>
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>
> unable to load shared library
> '/home/matt/R/lib64/R/library/gsl/libs/gsl.so':
>
> /home/matt/R/lib64/R/library/gsl/libs/gsl.so: undefined symbol:
> gsl_sf_expint_En_e
>
> Error: package/namespace load failed for 'gsl'
>
>
>
> It looks like it is due to where my Linux (not R) gsl package is
> installed. Robin thought the problem is that I had to install my
Linux
> gsl package in a nontypical location (it's in /usr) because /usr/local
> is not available to us.
>
>
>
> He mentioned that others have had this problem. Has anyone been able
to
> surmount this problem?
> Thanks,
>
> Matt
>
>
>
> PS. I'm running Suse Linux 10.3:
>
> Linux ghidra 2.6.22.19-0.1-default #1 SMP 2008-10-14 22:17:43 +0200
> x86_64 x86_64 x86_64 GNU/Linux
>
> Matthew J. Hoptman, PhD
> Research Scientist V
> Nathan S. Kline Institute for Psychiatric Research
>
> Research Associate Professor in Psychiatry
> NYU School of Medicine
>
>
>
> IMPORTANT NOTICE: This e-mail is meant only for the use of the
intended
> recipient. It may contain confidential information which is legally
> privileged or otherwise protected by law. If you received this
> e-mail in error or from someone who was not authorized to send it to
> you, you are strictly prohibited from reviewing, using, disseminating,
> distributing or copying the e-mail.
>
> PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE
> THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
>
>
>
>
>
> _
> Conserve resources. Print only when necessary.
>
> IMPORTANT NOTICE: This e-mail is meant only for the use of the
intended recipient. It may contain confidential information which is
legally privileged
> or otherwise protected by law. If you received this e-mail in error
or from someone who was not authorized to send it to you, you are
strictly prohibited
> from reviewing, using, disseminating, distributing or copying the
e-mail. PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND
DELETE THIS MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Dr. Martin Becker
Statistics and Econometrics
Saarland University
Campus C3 1, Room 206
66123 Saarbruecken
Germany
_
Conserve resources. Print only when necessary.
IMPORTANT NOTICE: This e-mail is meant only for the use of the intended
recipient. It may contain confidential information which is legally privileged
or otherwise protected by law. If you received this e-mail in error or from
someone who was not authorized to send it to you, you are strictly prohibited
from reviewing, using, disseminating, distributing or copying the e-mail.
PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND DELETE THIS
MESSAGE FROM YOUR SYSTEM. Thank you for your cooperation.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method in two packages
Doug wrote: > I think a simpler solution, which I have implemented in lme4 but not > yet released is to have > importFrom(nlme, ranef, fixef) > in the NAMESPACE file of packages that implement methods for those > generics (and, of course, add nlme to the Imports: specification in > the DESCRIPTION file). As nlme is a required package I don't think > this is too much of a burden. I'll do the same change in coxme. We can save Kevin Coombe's solution of a separate package of "method stubs" (which I find very similar in spirit to a shared .h file in C) for the day that ranef/fixef gets wildly popular. An importMethods directive for the namespace is an intriguing long term idea for the core team to ponder. Again, thanks fo all the input. This discussion has been very illuminating for me. Terry T. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] log2(quote(1:10)) evaluates the quoted 1:10, log() does not
This is very minor, but shouldn't log2(quote(1:10)) throw an error,the same as log() and other math functions do? It looks like log2 and log10 evaluate a call object instead of throwing a non-numeric-argument error. They do object to non-call language objects, like expressions. > log2(quote(1:10)) [1] 0.00 1.00 1.584963 2.00 2.321928 2.584963 [7] 2.807355 3.00 3.169925 3.321928 > log(quote(1:10)) Error in log(quote(1:10)) : Non-numeric argument to mathematical function > sqrt(quote(1:10)) Error in sqrt(quote(1:10)) : Non-numeric argument to mathematical function > quote(1:10) ^ 2 Error in quote(1:10)^2 : non-numeric argument to binary operator > 2 ^ quote(1:10) Error in 2^quote(1:10) : non-numeric argument to binary operator Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check issue with soft-linked directory
I've been having some strange problems with R CMD check in the last couple of days, but now believe I have localized the issue. I had been running Ubuntu Hardy on one drive and then upgraded to Jaunty, but put Jaunty on a different drive. I continue to be able to boot Hardy when I wish. I soft-linked my R working area i.e., /home/john/Rstuff >/media/lnx804/home/john/Rstuff I can still build packages fine, but get j...@nsrv-jaunty:~/jtest$ R CMD check minqa * checking for working pdflatex ... OK * using log directory '/media/store2/jn/test/minqa.Rcheck' * using R version 2.10.1 (2009-12-14) * using session charset: UTF-8 * checking for file 'minqa/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'minqa' version '1.02' * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'minqa' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking for sufficient/correct file permissions ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for non-ASCII characters ... OK * checking R files for syntax errors ... OK * checking whether the package can be loaded ... ERROR Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/media/store2/jn/test/minqa.Rcheck/minqa/libs/minqa.so': /media/store2/jn/test/minqa.Rcheck/minqa/libs/minqa.so: failed to map segment from shared object: Operation not permitted Error : .onLoad failed in 'loadNamespace' for 'minqa' Error: package/namespace load failed for 'minqa' Execution halted It looks like this package has a loading problem: see the messages for details. The above test was run with a newly created jtest/ directory on yet another drive (partition) to see if there was possibly corruption. However, the issue seems to be one of using a softlink. I would not be upset if R CMD check simply told me that this isn't the right way to do things i.e., don't use the softlinked directory. Does anyone know if this is a recognized issue and is it possible to put some sort of reasonable error message into R CMD check? JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Using R in a corporate envinronment
If you're looking for business and technical justifications for a business to adopt R, I wrote some up last year: http://blog.revolution-computing.com/2009/02/how-to-get-it-to-accept-and-love-r.html In summary: R is mainstream R is supported R is high-quality R leads commercial packages in innovation R is cost effective Ironically, for many companies #1 is more important than #5, so pointing to other companies using R is often a good strategy (see http://blog.revolution-computing.com/rmedia/ for some media articles that may help). And also (if I may indulge the list for a small plug) some companies are more comfortable paying for open-source software than installing it free of cost (for the support, validation, and so on). If that's the case for your company, there's REvolution R Enterprise: http://www.revolution-computing.com/products/revolution-enterprise.php Hope this helps, # David Smith -- David M Smith VP of Marketing, REvolution Computing http://blog.revolution-computing.com Tel: +1 (650) 330-0553 x205 (Palo Alto, CA, USA) Download REvolution R free: www.revolution-computing.com/downloads/revolution-r.php On Wed, Mar 10, 2010 at 10:07 AM, Fernando Henrique Ferraz Pereira da Rosa wrote: > > Dear r-useRs, > > After a couple of years in a 'R exile' of sorts, I've recently changed jobs > and my current employer (an American multinational in the food manufacturing > industry) is much more open than my past employer (which wouldn't even want > to hear about anything that didn't begin with SAS...). So, after my > insistence corporate IT is now considering adopting R as part of our > statistical applications toolbox. > > Things are not that simple though, and I'm now in the process of collecting > data for writing a Business Case for R in our corporation, and this is the > reason I'm writing you. If you have any examples (preferably with > references) and/or experience in a similar scenario please do write me. I've > already googled for some materials, and there's an excellent piece on the > NyTimes of last year, which pointed that even Google was adopting R, and > this is exactly the sort of thing I need to help convincing IT they'll be > making a sound choice in adopting R. > > Thanks in advance for your attention, > > Fernando Rosa > > -- > "Though this be randomness, yet there is structure in't." > Rosa, F.H.F.P > > Instituto de Matemática e Estatística > Universidade de São Paulo > Fernando Henrique Ferraz P. da Rosa > http://www.feferraz.net > > [[alternative HTML version deleted]] > > > __ > r-h...@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check issue with soft-linked directory
On Mar 10, 2010, at 12:43 , Prof. John C Nash wrote: I've been having some strange problems with R CMD check in the last couple of days, but now believe I have localized the issue. I had been running Ubuntu Hardy on one drive and then upgraded to Jaunty, but put Jaunty on a different drive. I continue to be able to boot Hardy when I wish. I soft-linked my R working area i.e., /home/john/Rstuff >/media/lnx804/home/john/Rstuff I can still build packages fine, but get j...@nsrv-jaunty:~/jtest$ R CMD check minqa * checking for working pdflatex ... OK * using log directory '/media/store2/jn/test/minqa.Rcheck' * using R version 2.10.1 (2009-12-14) * using session charset: UTF-8 * checking for file 'minqa/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'minqa' version '1.02' * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'minqa' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking for sufficient/correct file permissions ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for non-ASCII characters ... OK * checking R files for syntax errors ... OK * checking whether the package can be loaded ... ERROR Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/media/store2/jn/test/minqa.Rcheck/ minqa/libs/minqa.so': /media/store2/jn/test/minqa.Rcheck/minqa/libs/minqa.so: failed to map segment from shared object: Operation not permitted Error : .onLoad failed in 'loadNamespace' for 'minqa' Error: package/namespace load failed for 'minqa' Execution halted It looks like this package has a loading problem: see the messages for details. The above test was run with a newly created jtest/ directory on yet another drive (partition) to see if there was possibly corruption. However, the issue seems to be one of using a softlink. I would be very surprised if this was softlink's fault per se. It looks more like a permission issue in your system to me -- the first thing I would check is that your /media/... is not mounted with noexec... Cheers, Simon I would not be upset if R CMD check simply told me that this isn't the right way to do things i.e., don't use the softlinked directory. Does anyone know if this is a recognized issue and is it possible to put some sort of reasonable error message into R CMD check? JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check issue with soft-linked directory
Good catch Simon. Changed fstab to force exec on mount of the drive in question and things worked. Thanks, JN Simon Urbanek wrote: On Mar 10, 2010, at 12:43 , Prof. John C Nash wrote: I've been having some strange problems with R CMD check in the last couple of days, but now believe I have localized the issue. I had been running Ubuntu Hardy on one drive and then upgraded to Jaunty, but put Jaunty on a different drive. I continue to be able to boot Hardy when I wish. I soft-linked my R working area i.e., /home/john/Rstuff >/media/lnx804/home/john/Rstuff I can still build packages fine, but get j...@nsrv-jaunty:~/jtest$ R CMD check minqa * checking for working pdflatex ... OK * using log directory '/media/store2/jn/test/minqa.Rcheck' * using R version 2.10.1 (2009-12-14) * using session charset: UTF-8 * checking for file 'minqa/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'minqa' version '1.02' * checking package name space information ... OK * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'minqa' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking for sufficient/correct file permissions ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for non-ASCII characters ... OK * checking R files for syntax errors ... OK * checking whether the package can be loaded ... ERROR Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/media/store2/jn/test/minqa.Rcheck/minqa/libs/minqa.so': /media/store2/jn/test/minqa.Rcheck/minqa/libs/minqa.so: failed to map segment from shared object: Operation not permitted Error : .onLoad failed in 'loadNamespace' for 'minqa' Error: package/namespace load failed for 'minqa' Execution halted It looks like this package has a loading problem: see the messages for details. The above test was run with a newly created jtest/ directory on yet another drive (partition) to see if there was possibly corruption. However, the issue seems to be one of using a softlink. I would be very surprised if this was softlink's fault per se. It looks more like a permission issue in your system to me -- the first thing I would check is that your /media/... is not mounted with noexec... Cheers, Simon I would not be upset if R CMD check simply told me that this isn't the right way to do things i.e., don't use the softlinked directory. Does anyone know if this is a recognized issue and is it possible to put some sort of reasonable error message into R CMD check? JN __ 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] Shrinking a List
Hello, I create a VECSXP(call it A) with size N(~ 5000), i then proceed to fill the elements and find out I don't need to fill more than M (M<< N). Thus if i return A to the user's R code, he/she will see a list of length 5K of which N-M are NULLs. To avoid this, I create a new VECSXP B of length M and /duplicate/ the elements of A. Since I do this often, it appears to be wasteful, so can I a) is there a resize function for a VECSXP? if not b) can i just do something like SET_VECTOR_ELT(B,i, VECTOR_ELT(A,i)) instead of wrapping VECTOR_ELT(A,i) inside a call to Rf_duplicate (i will be UNPROTECTING A and B, though I will return B) I suppose I can do (b), since B (since it is being returned) is automatically protected and therefore all its elements will also be protected, correct? Thank you Saptarshi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] application to mentor syrfr package development for Google Summer of Code 2010
Michael, Thanks for your reply with the information about the Eureqa API -- I am forwarding it to the r-devel list below. Dirk, Will you please agree to referring to the syrfr package as symbolic genetic algorithm regression of functions but not (yet) general relations? It would be best to refer to general relation regression as a future package, something like 'syrr' and leave the parametrization of the derivatives to that package. May I please mentor, in consultation with Michael if necessary, work on general function regressions while Chillu and John Nash work on the derivative package necessary for general relation regressions? Thank you for your kind consideration. Best regards, James Salsman On Tue, Mar 9, 2010 at 11:06 AM, Michael Schmidt wrote: > I think it's a great idea worth trying out. We have always done significance > tests just on the final frontier of models as a post processing step. Moving > this into the algorithm could focus the search more on significant higher > quality solutions. One thing to beware of though is that using parsimony > pressure just on the number of free parameters tends to focus the search on > complex equations with no free parameters. So, some care should be taken how > to implement it. > > We do see a measurable improvement using crossover versus just mutation on > random test problems. Empirically, it doesn't seem necessary for all > problems but also doesn't seem to ever inhibit the search. > > I didn't know that anyone was working on a SR package for R. Very cool! I'm > happy to consult if you have any questions I can help with. > > You may also be interested that we just recently opened up the API for > interacting with Eureqa servers: > http://code.google.com/p/eureqa-api/ > If you know of anyone that might be interested in making a wrapper for R, > please forward. > > Michael > > > On Mon, Mar 8, 2010 at 5:45 PM, James Salsman > wrote: >> >> Michael, >> >> Thanks for your reply: >> >> On Mon, Mar 8, 2010 at 12:41 AM, Michael Schmidt >> wrote: >> > >> > Thanks for contacting me. Eureqa takes into account the total size of an >> > equation when comparing different candidate models. It attempts to find >> > the >> > set of possible equations that are non-dominated in both error and size. >> > The >> > final results is a short list consisting of the most accurate equation >> > for >> > increasing equation sizes. >> > >> > This is closely related to degrees of freedom, but not exactly the same >> >> That's very good, but I wonder whether we can perform automatic >> outlier exclusion that way. We would need to keep the confidence >> interval, or at least the information necessary to derive it, accurate >> in every step of the genetic beam search. Since the confidence >> intervals of extrapolation depend so heavily on the number of degrees >> of freedom of the fit (along with the residual standard error) it's a >> good idea to use a degree-of-freedom-adjusted F statistic instead of a >> post-hoc combination of equation size and residual standard error, I >> would think. You might want to try it and see how it improves things. >> Confidence intervals, by representing the goodness of fit in the >> original units and domain of the dependent variable, are tremendously >> useful and sometimes make many kinds of tests which would otherwise be >> very laborious easy to eyeball. >> >> Being able to fit curves to one-to-many relations instead of strict >> one-to-one functions appeals to those working in the imaging domain, >> but not to as many traditional non-image statisticians. Regressing >> functions usually results in well-defined confidence intervals, but >> regressing general relations with derivatives produces confidence >> intervals which can also be relations. Trying to figure out a >> spiral-shaped confidence interval probably appeals to astronomers more >> than most people. So I am proposing that, for R's contemplated >> 'syrfr' symbolic regression package, we do functions in a general >> genetic beam search framework, Chillu and John Nash can do derivatives >> in the new 'adinr' package, and then we can try to put them together, >> extend the syrfr package with a parameter indicating to fit relations >> with derivatives instead of functions, to try to replicate your work >> on Eureqa using d.o.f-adjusted F statistics as a heuristic beam search >> evaluation function. >> >> Have you quantified the extent to which using the crossover rule in >> the equation tree search is an improvement over mutation alone in >> symbolic regression? I am glad that Chillu and Dirk have already >> supported that; there is no denying its utility. >> >> Would you like to co-mentor this project? >> http://rwiki.sciviews.org/doku.php?id=developers:projects:gsoc2010:syrfr >> I've already stepped forward, so you could do as much or as little as >> you like if you wanted to co-mentor and Dirk agreed to that >> arrangement. >> >> Best regards, >> James Salsman >> >> >> >
Re: [Rd] Shrinking a List
And how would you do this at R level? I would use length(A) <- M, and the corresponding C function is lengthgets. Of course, the wasteful part is to create a far-too-long vector in the first place, rather than growing it as needed. On Wed, 10 Mar 2010, Saptarshi Guha wrote: Hello, I create a VECSXP(call it A) with size N(~ 5000), i then proceed to fill the elements and find out I don't need to fill more than M (M<< N). Thus if i return A to the user's R code, he/she will see a list of length 5K of which N-M are NULLs. To avoid this, I create a new VECSXP B of length M and /duplicate/ the elements of A. Since I do this often, it appears to be wasteful, so can I a) is there a resize function for a VECSXP? if not b) can i just do something like SET_VECTOR_ELT(B,i, VECTOR_ELT(A,i)) instead of wrapping VECTOR_ELT(A,i) inside a call to Rf_duplicate (i will be UNPROTECTING A and B, though I will return B) I suppose I can do (b), since B (since it is being returned) is automatically protected and therefore all its elements will also be protected, correct? Thank you Saptarshi __ 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
