[Rd] Writing new probability functions
Dear developeRs, I am maintaining a package of Actuarial Science functions (soon to be uploaded to CRAN) in which we would like to include the usual d*, p*, q* and r* functions for some probability laws not currently found in base R. Taking into account that most of the distributions are functions or transformations of the distributions found in base R, should we look into writing our functions in C or in R, both in terms of: (1) speed, and (2) accuracy? If we opt for C, is there a canonical reference detailing the precautions one has to take to ensure accuracy of the density/distribution/quantile functions over the complete domain of the probability laws? Comments appreciated. -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] arr.ind argument to which.min and which.max
Le lun. 5 juil. à 05:56, Martin Maechler a écrit :
>> "PatB" == Patrick Burns
>>on Sun, 04 Jul 2010 09:43:44 +0100 writes:
>
>PatB> Is there a reason that 'which.min' and
>PatB> 'which.max' don't have an 'arr.ind'
>PatB> argument?
>
> well, help(which.min) tells you that they really were aimed at
> doing their job *fast* for vectors.
>
> Of course you are right and a generalization to arrays might be
> convenient at times.
>
>PatB> The context in which I wanted that was
>PatB> a grid search optimization, which seems
>PatB> like it would be reasonably common to me.
>
> well, as the author of these two functions, I can only say
>
> "patches are welcome!"
>
> and I think should be pretty simple, right ?
> You just have to do very simple remapping of the 1d index 'i' back
> to the array index, i.e., the same operation
> you need to transform seconds into days:hours:minutes:seconds
> {{and yes, we old-timers may recall that APL had an operator (I
> think "T-bar") to do that ...}
Ah, a reference to APL! That made my day. :-)
APL was very big among actuaries for a long time. I heard recently that it was
still in use on an old system in some small insurance company. I still have on
my shelves the reference books for APL*Plus III for Windows (that I ran in
OS/2) from Magnugistics; they have an actuarial formula on the cover.
I teach my students arbitrary base conversion to do just what the encode/decode
operators (to call them by their names) were doing. I see this new arrayInd()
sort of does the same thing now. Darn, this steals me an exercise!
Cheers,
Vincent
>
> Martin Maechler, ETH Zurich
>
>
>PatB> --
>PatB> Patrick Burns
>PatB> pbu...@pburns.seanet.com
>PatB> http://www.burns-stat.com
>PatB> (home of 'Some hints for the R beginner'
>PatB> and 'The R Inferno')
>
> __
> 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] Suggested tidying up
Package grDevices has a function cm() to convert from inches to centimeters.
Its definition is:
cm <- function(x) 2.54*x
As far as I can tell, the function is not used anywhere in the R sources (I
grepped for "cm(", "cm)" and ", cm".) I did not check for all packages on CRAN,
though.
May I propose to remove this apparently useless function from the sources?
[I stubbled upon this function because my package actuar also has a cm()
function that masks the one from grDevices.]
Dr. Vincent Goulet
Full Professor
École d'actuariat, Université Laval, Québec
vincent.gou...@act.ulaval.ca http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning from install.packages()
Le jeu. 3 juin à 09:27, Ben Bolker a écrit :
> Martin Maechler wrote:
>>>>>>> "BB" == Ben Bolker
>>>>>>>on Wed, 02 Jun 2010 13:45:18 -0400 writes:
>>
>>BB> Michael Dewey wrote:
>>>> At 13:40 01/06/2010, Ben Bolker wrote:
>>>>
>>>>>> On 25/05/10 23:25 PM, "Ben Bolker" ufl.edu> wrote:
>>>>>> Just curious: is there a particular reason why install.packages()
>>>>>> gives a warning in normal use when 'lib' is not specified (e.g. argument
>>>>>> 'lib' is missing: using '/usr/local/lib/R/site-library' )?
>>>>
>>>> As I see it R is saying 'I am doing what you told
>>>> me, but just in case I am checking whether that
>>>> was what you really wanted'. Note that you do not
>>>> get a warning if there was only one place R could
>>>> put it. I would certainly vote for a message if
>>>> people are getting unnecessarily alarmed by the warning.
>>
>>BB> But this seems so different from R's general philosophy/behavior
>>BB> (inherited from Unix?) that a function that gets correct input and
>>BB> executes without error returns silently ...
>>
>> That's correct.
>> Note however that installing a package is not just a thing
>> happening in your R session.
>> It will affect all your future R sessions, and possibly even
>> other users' who have the same .libPaths()[1]
>> {e.g. the group here does share it}.
>>
>> I'd agree to not put a warning but I'd definitely want a message
>> aka "note" to the user.
>> The *wording* of that note should not be alarming at all, I
>> agree, just a note to the user.
>>
>> Martin Maechler, ETH Zurich
>
> OK, then, how about this as a minimal change?
>
> ===
> --- packages.R(revision 52192)
> +++ packages.R(working copy)
> @@ -534,8 +534,8 @@
>
> if(missing(lib) || is.null(lib)) {
> lib <- .libPaths()[1L]
> -warning(gettextf("argument 'lib' is missing: using %s", lib),
> -immediate. = TRUE, domain = NA)
> +message(gettextf("argument 'lib' is missing: using %s", lib),
> +domain = NA)
> }
>
> paths <- .find.package(pkgs, lib)
> Index: packages2.R
> ===
> --- packages2.R (revision 52192)
> +++ packages2.R (working copy)
> @@ -193,8 +193,8 @@
> if(missing(lib) || is.null(lib)) {
> lib <- .libPaths()[1L]
> if(length(.libPaths()) > 1L)
> -warning(gettextf("argument 'lib' is missing: using '%s'", lib),
> -immediate. = TRUE, domain = NA)
> +message(gettextf("argument 'lib' is missing: using '%s'", lib),
> +domain = NA)
> }
>
> ## check for writability by user
I wholeheartedly support the change discussed here since it is also something
that has been worrying my students for some time.
However, I think saying "argument 'lib' not specified: using '%s'" would be
even less alarming. "... is missing" sort of implies the user forgot something.
My 0.02 $
Dr. Vincent Goulet
Full Professor
École d'actuariat, Université Laval, Québec
vincent.gou...@act.ulaval.ca http://vgoulet.act.ulaval.ca
>
>
> --
> Ben Bolker
> Associate professor, Biology Dep't, Univ. of Florida
> *** NEW E-MAIL ADDRESSES:
> *** bbol...@gmail.com , bol...@math.mcmaster.ca
> bol...@ufl.edu / people.biology.ufl.edu/bolker
> GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
Le Vendredi 23 Février 2007 05:49, mel a écrit : > Dear all, > > I have to develop a (hopefully) small package for R in C++. > I didn't code in C++ for some years, and i'm now searching > for an adequate IDE for this task. > > Some of my criterions : not proprietary, not too heavy, > open to linux, not java gasworks, still maintained, etc > > After looking on several places > http://en.wikipedia.org/wiki/List_of_C%2B%2B_compilers_and_integrated_devel >opment_environments http://www.freeprogrammingresources.com/cppide.html > + R docs > I was thinking on code::blocks, and emacs (and perhaps vim) > > Emacs seems used by some R developers as an R editor. > So i did think on emacs because it could perhaps be interesting > to have the same editor for R code and C++ code. > > However, when looking at the last emacs windows version, > it seems to date from january 2004 ... (dead end ?) > ftp://ftp.gnu.org/pub/gnu/emacs/windows/ > > I will be grateful for all advices on this tool topic. > Better choosing emacs ? or code::blocks ? > or another idea ? > Does somebody have an idea about the most used IDEs for > R C++ package writing ? So, many other people told you that Emacs is a good choice. If you want to try it out, I also maintain a modified version of GNU Emacs that is simple to install and works with ESS and the latest version of R out of the box: http://vgoulet.act.ulaval.ca/emacs Please note that the bells and whistles of EmacsW32 are not included. It is a plain GNU Emacs 21.3 with AUCTeX, ESS, Aspell and other minor enhancements thrown in. HTH -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] C function with unknown output length
Hi all, Could anyone point me to one or more examples in the R sources of a C function that is called without knowing in advance what will be the length (say) of the output vector? To make myself clearer, we have a C function that computes probabilities until their sum gets "close enough" to 1. Hence, the number of probabilities is not known in advance. I would like to have an idea what is the best way to handle this situation in R. Thanks in advance! --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C function with unknown output length
Le 07-06-06 à 15:20, Herve Pages a écrit :
> Vincent Goulet wrote:
>> Hi all,
>>
>> Could anyone point me to one or more examples in the R sources of a C
>> function that is called without knowing in advance what will be the
>> length (say) of the output vector?
>>
>> To make myself clearer, we have a C function that computes
>> probabilities until their sum gets "close enough" to 1. Hence, the
>> number of probabilities is not known in advance.
>>
>
> Hi Vincent,
>
> Let's say you want to write a function get_matches(const char *
> pattern, const char * x)
> that will find all the occurrences of string 'pattern' in string
> 'x' and "return"
> their positions in the form of an array of integers.
> Of course you don't know in advance how many occurrences you're
> going to find.
>
> One possible strategy is to:
>
> - Add an extra arg to 'get_matches' for storing the positions and
> make
> 'get_matches' return the number of matches (i.e. the length of
> *pos):
>
> int get_matches(int **pos_ptr, const char * pattern, const
> char * x)
>
> Note that pos_ptr is a pointer to an int pointer.
>
> - In get_matches(): use a local array of ints and start with an
> arbitrary
> initial size for it:
>
> int get_matches(...)
> {
> int *tmp_pos, tmp_size, npos = 0;
>
> tmp_size = some initial guess of the number of matches
> tmp_pos = (int *) S_alloc((long) tmp_size, sizeof(int));
> ...
>
> Then start searching for matches and every time you find one,
> store its
> position in tmp_pos[npos] and increase npos.
> When tmp_pos is full (npos == tmp_size), realloc with:
>
> ...
> old_size = tmp_size;
> tmp_size = 2 * old_size; /* there are many different
> strategies for this */
> tmp_pos = (int *) S_realloc((char *) tmp_pos, (long) tmp_size,
> (long) old_tmp_size, sizeof(int));
> ...
>
> Note that there is no need to check that the call to S_alloc()
> or S_realloc()
> were successful because these functions will raise an error and
> end the call
> to .Call if they fail. In this case they will free the memory
> currently allocated
> (and so will do on any error or user interrupt).
>
> When you are done, just return with:
>
> ...
> *pos_ptr = tmp_pos;
> return npos;
> }
>
> - Call get_matches with:
>
> int *pos, npos;
>
> npos = get_matches(&pos, pattern, x);
>
> Note that memory allocation took place in 'get_matches' but now
> you need
> to decide how and when the memory pointed by 'pos' will be freed.
> In the R environment, this can be addressed by using
> exclusively transient
> storage allocation (http://cran.r-project.org/doc/manuals/R-
> exts.html#Transient)
> as we did in get_matches() so the allocated memory will be
> automatically
> reclaimed at the end of the call to .C or .Call.
> Of course, the integers stored in pos have to be moved to a
> "safe" place
> before .Call returns. Typically this will be done with
> something like:
>
> SEXP Call_get_matches(...)
> {
> ...
> npos = get_matches(&pos, pattern, x);
> PROTECT(pos_sxp = NEW_INTEGER(npos));
> memcpy(INTEGER(pos_sxp), pos, npos * sizeof(int));
> UNPROTECT(1);
> return pos_sxp; /* end of call to .Call */
> }
>
> There are many variations around this. One of them is to "share"
> pos and npos between
> get_matches and its caller by making them global variables (in this
> case it is
> recommended to use 'static' in their declarations but this requires
> that get_matches
> and its caller are in the same .c file).
>
> Hope this helps.
It did, thanks Herve. And thanks also to Dirk and Bill for their
useful suggestions.
We (actually, my student, but in pure academia style I'll take part
of the credit ;-) had done something very similar to Herve's
suggestion, including the "double the size when it's full" strategy,
but in one function only instead of two. Now I got confirmation it
was a good way to go. I'm satisfied.
Best,Vincent
>
> H.
>
>> I would like to have an idea what is the best way to handle this
>> situation in R.
>>
>> Thanks in advance!
>>
>> ---
>>Vincent Goulet, Associate Professor
>>École d'actuariat
>>Université Laval, Québec
>>[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] developing a package: increase the number of functions
Le 07-07-31 à 09:48, Gregor Gorjanc a écrit : > Prof Brian Ripley stats.ox.ac.uk> writes: > ... >> >> Do you have a NAMESPACE? > > Hi Albart! > > About the NAMESACE issue. Functions that are specified in NAMESPACE > are available when you install a package, while internal ones can > only be accessed with > > myInternalFun:::myPackage Or rather myPackage:::myInternalFun > > Gregor > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Matrix exponential in R
Dear developeRs, The topic has been raised quite a few times in r-devel and r-help before: calculation of matrix exponentials in R. We needed it in the actuar package at the C level and ended up cooking up our own solution based on expm() of package Matrix (which is itself based on Octave's). If there is interest from the R Core Team, we (my colleague in CC and I) are offering to contribute an expm() function to base R, with the corresponding C function part of the R API for package authors to use. We feel this would be a welcome addition to base R. Please share your thoughts. Best, --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in r-base (PR#10521)
[Moved from r-devel] Le mar. 18 déc. à 10:35, [EMAIL PROTECTED] a écrit : > Full_Name: marco zamboni > Version: no R version > OS: ubuntu gusty > Submission from: (NULL) (87.9.174.188) > > > I have just finish to install gusty ubuntu on my AMD sempron. > I would like to: > $ sudo apt-get install r-base > > but > ... > I seguenti pacchetti hanno dipendenze non soddisfatte: > r-base: Dipende: r-base-core (>= 2.6.1-1gutsy0) ma 2.5.1-1 sta per > essere > installato > Dipende: r-recommended (= 2.6.1-1gutsy0) ma non sta per > essere > installato > E: Pacchetto non integro First, this is not a bug with R at all; only a difficulty you have with installing the r-base package. Second, this does not belong to r-devel, but to r-sig-debian. Hence the discussion is moved to the latter forum. Now, did you follow the instructions in the Ubuntu README at http://cran.r-project.org/bin/linux/ubuntu/ ? What is the result of apt-cache policy r-base ? We should be able to help you with this information. Best, --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small encoding question
Dear developeRs, Compilation of the latest version (0.9-5) of my actuar package fails with r-release MacOS_X ix86 on CRAN; see http://www.R-project.org/nosvn/R.check/r-release-macosx-ix86/actuar-00check.html All errors come from accented letters in comments in latin-1 encoded files (except hierarc.R which is in UTF-8, my bad). Encoding is declared as latin-1 in DESCRIPTION. The package checks and compiles fine on Windows, Linux and, ironically, my MacOS X main development machine. I realize using non- ASCII characters in source files is not a good idea and I removed them, but I would appreciate any clue as to what went wrong with the compilation on CRAN. FWIW, > sessionInfo() R version 2.6.2 (2008-02-08) i386-apple-darwin8.10.1 locale: fr_CA.UTF-8/fr_CA.UTF-8/fr_CA.UTF-8/C/fr_CA.UTF-8/fr_CA.UTF-8 attached base packages: [1] stats utils datasets grDevices graphics methods base other attached packages: [1] CarbonEL_0.1-4 loaded via a namespace (and not attached): [1] tools_2.6.2 Thanks in advance! --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to create a function calling two functions with unknown number of parameters?
Le ven. 4 avr. à 18:03, ZT2008 a écrit :
>
>
> ... can be used to represent unknown number of parameters passed
> into a
> function.
>
> For example, I write a function g. g calls another function f1.
>
> For example f1 could be different random number generation function.
>
> when f1=rnorm(), it has 3 parameters n, mean and standard deviation.
>
> when f1=rexp(), it has 2 parameters n and rate.
>
> g can be defined as
>
> g <- function(f1, ...) {
> f1(...)
> }
>
> My problem is what about g calls two functions with unknown number of
> parameters.
>
> In this case one ... doesn't help.
>
> If I define g as follows:
>
> g <- function(f1, f2, ...) {
> f1(...)+f2(...)
> }
>
> It seems ... is only passed to f1, it can't be passed to f2.
You should get around what you want with something along the lines of
dots <- list(...)
argf <- formals(f)
argg <- formals(g)
and then extracting from 'dots' elements corresponding to 'argf' and
'argg' (using their names).
HTH
>
>
> Can anybody help me? Thanks!
>
> --
> View this message in context:
> http://www.nabble.com/How-to-create-a-function-calling-two-functions-with-unknown-number-of-parameters--tp16501233p16501233.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
---
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adding a Matrix Exponentiation Operator
Le dim. 6 avr. à 07:01, Rory Winston a écrit :
> Hi Martin
>
> Thanks for the detailed reply. I had a look at the matrix power
> implementation in the actuar package and the modified version in the
> expm
> package. I have a couple of questions/comments:
>
> 1. Firstly, I seem to have trouble loading expm.
>
>> install.packages("expm",repos="http://R-Forge.R-project.org";)
> trying URL '
> http://R-Forge.R-project.org/bin/macosx/universal/contrib/2.6/expm_0.9-1.tgz
> '
> Content type 'application/x-gzip' length 149679 bytes (146 Kb)
> opened URL
> ==
> downloaded 146 Kb
> ...
>> library("expm")
> Error in namespaceExport(ns, exports) : undefined exports :matpow
> Error: package/namespace load failed for 'expm'
[snip]
The current version of the package on R-Forge is 0.9-2 and the
NAMESPACE issue should be fixed there.
> 2. On to the package implementation, I see we actually have very
> similar
> implementations. The main differences are:
>
> i) For an exponent equal to -1, I call back into R for the solve()
> function
> using eval() and CAR/CDR'ing the arguments into place. The actuar
> package
> calls dgesv() directly. I suspect that the direct route is more
> efficient
> and thus the more preferable one. I see that your implementation
> doesnt
> calculate the inverse for an exponent of -1,is there a specific
> reason for
> doing that?
The rationale is: you seldom *really* need to inverse a matrix, so we
won't help you go that route. If you *really* need the explicit
inverse, then use solve() directly (as the error message says).
> ii) Regarding complex matrices: I guess we should have support for
> this, as
> its not unreasonable that someone may do this, and it should be
> pretty easy
> to implement. My function doesnt have full support yet.
>
> iii) A philosophical question - where the the "right" place for the
> %^%
> operator? Is it in the operator list at a C level along with %*% and
> the
> like? Or is it in an R file as a function definition?
Well... both. The operator %^% is defined at the R level but the
computations are done at the C level by function matpow(). Or perhaps
I didn't understand what you mean, here.
> I dont really have a
> preference either way...have you an opinion on this?
>
> Thanks
> Rory
HTH
Vincent
>
>
>
> On Sat, Apr 5, 2008 at 6:52 PM, Martin Maechler <[EMAIL PROTECTED]
> >
> wrote:
>
>>> "RW" == Rory Winston <[EMAIL PROTECTED]>
>>>on Sat, 5 Apr 2008 14:44:44 +0100 writes:
>>
>> RW> Hi all I recently started to write a matrix
>> RW> exponentiation operator for R (by adding a new operator
>> RW> definition to names.c, and adding the following code to
>> RW> arrays.c). It is not finished yet, but I would like to
>> RW> solicit some comments, as there are a few areas of R's
>> RW> internals that I am still feeling my way around.
>>
>> RW> Firstly:
>>
>> RW> 1) Would there be interest in adding a new operator %^%
>> RW> that performs the matrix equivalent of the scalar ^
>> RW> operator?
>>
>> Yes. A few weeks ago, I had investigated a bit about this and
>> found several R-help/R-devel postings with code proposals
>> and then about half dozen CRAN packages with diverse
>> implementations of the matrix power (I say "power" very much on
>> purpose, in order to not confuse it with the matrix exponential
>> which is another much more interesting topic, also recently (+-
>> two months?) talked about.
>>
>> Consequently I made a few timing tests and found that indeed,
>> the "smart matrix power" {computing m^2, m^4, ... and only those
>> multiplications needed} as you find it in many good books about
>> algorithms and e.g. also in *the* standard Golub & Van Loan
>> "Matrix Computation" is better than "the eigen" method even for
>> large powers.
>>
>> matPower <- function(X,n)
>> ## Function to calculate the n-th power of a matrix X
>> {
>> if(n != round(n)) {
>> n <- round(n)
>> warning("rounding exponent `n' to", n)
>> }
>> if(n == 0)
>> return(diag(nrow = nrow(X)))
>> n <- n - 1
>> phi <- X
>> ## pot <- X # the first power of the matrix.
>> while (n > 0)
>> {
>> if (n %% 2)
>> phi <- phi %*% X
>> if (n == 1) break
>> n <- n %/% 2
>> X <- X %*% X
>> }
>> return(phi)
>> }
>>
>> "Simultaneously" people where looking at the matrix exponential
>> expm() in the Matrix package,
>> and some of us had consequently started the 'expm' project on
>> R-forge.
>> The main goal there has been to investigate several algorithms
>> for the matrix exponential, notably the one buggy implementation
>> (in the 'Matrix' package until a couple of weeks ago, the bug
>> stemming from 'octave' implementation).
>> The authors of 'actuar', Vincent and Christophe, notably also
>> had code for the matrix *power* in a C (building on BLAS) and I
>> had added an R-interface '%^%' there as well.
>>
>> Yes, with the goal t
Re: [Rd] HOW TO AVOID LOOPS
Le sam. 12 avr. à 12:47, carlos martinez a écrit : >> Looking for a simple, effective a minimum execution time solution. >> >> For a vector as: >> >> c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1) >> > To transform it to the following vector without using any loops: > >> (0,0,1,0,1,2,3,0,0,1,2,0,1,0,1,2,3,4,5,6) >> > Appreciate any suggetions. This does it -- but it is admittedly ugly: > x <- c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1) > ind <- which(x == 0) > unlist(lapply(mapply(seq, ind, c(tail(ind, -1) - 1, length(x))), function(y) cumsum(x[y]))) [1] 0 0 1 0 1 2 3 0 0 1 2 0 1 0 1 2 3 4 5 6 (The mapply() part is used to create the indexes of each sequence in x starting with a 0. The rest is then straightforward.) HTH --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: R_Visible" (PR#11265)
Le ven. 25 avr. à 07:09, Dirk Eddelbuettel a écrit :
>
> On 24 April 2008 at 20:20, [EMAIL PROTECTED] wrote:
> | Full_Name: Jakob Stoeger
> | Version: 2.7.0
> | OS: ubuntu 7.10
> | Submission from: (NULL) (137.248.74.38)
> |
> |
> | Hi!
> |
> | I hope, it is justified to write this email...
> | I'm relatively new to linux, and haven't worked with r, yet, so
> please pardon
> | any things I do not know...
> |
> | I tried installing r on my computer, and didn't manage to get the
> program
> | running.
> | After having installed littler, typing r into the bash results in
> following
> | message:
> |
> | r: symbol lookup error: r: undefined symbol: R_Visible
>
> You need to rebuild littler ('r') against the new version of R ('R').
>
> I did that for Debian, looks like Ubuntu could do with it too. Your R
> version was provided by volunteers outside of Ubuntu.
>
> Vincent: In a perfect world, could you rebuild littler and provide it?
I'm not convinced this was the problem (probably more the case issue
raised by others), but heck, it was simple to build packages for
littler. On their way to CRAN now.
*However*, I won't commit to always maintain this package for Ubuntu.
Our general policy is to provide up-to-date binaries for the
Recommended packages only.
HTH Vincent
>
>
> Jakob: Barring a new littler you can apt-get, the easiest may be to
> just
> uninstall littler and rebuild it locally so that thew R 2.7.0 is used.
> Ping me, or better still, the r-sig-debian list, with questions if
> you have
> any. You need to subscribe to r-sig-debian before you can post there.
>
> Lastly, if you only want or use R, use R :) 'r' is for scripting
> and short
> command-line uses.
>
> Dirk
>
> PS It is the same with RPy.
>
> | I found a bugreport here:
> | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418686
> | I'm not sure, if this has anything to do with it, as it concerns
> rkward...
> |
> | Anyway, this information might come handy:
> | my system:
> | ubuntu 7.10
> | Kernel 2.6.22-14-generic
> | GNOME 2.20.1
> |
> | installed packages:
> | r-base 2.7.0-1gutsy0
> | r-base-core 2.7.1gutsy0
> | r-cran-cluster 1.11.10-1gutsy0
> | r-cran-boot 1.2.32-1gutsy0
> | r-cran-cluster 1.11.10-1gutsy0
> | r-cran-codetools 0.2-0-1gutsy0
> | r-cran-foreign 0.8.24-1gutsy0
> | r-cran-kernsmooth 2.22.22-1gutsy0
> | r-cran-lattice 0.17-6-1gutsy0
> | r-cran-mgcv 1.3-30-1gutsy0
> | r-cran-nlme 3.1.88-1gutsy0
> | r-cran-rpart 3.1.41-1gutsy0
> | r-cran-survival 2.34-1gutsy0
> | r-cran-vr 7.2.41-1gutsy0
> |
> | rkward 0.4.7a-1ubuntu1
> |
> | r-recommended 2.7.0-1gutsy0
> |
> |
> | I can't guarantee, that this list is complete, as I don't know
> (yet), how to
> | check for it...
> |
> | Not really relevant, but I feel that I should tell you:
> |
> | The university at which I study used to use SPSS. Until this term,
> from which on
> | we will officially use r. Yeah!
> |
> | So, I hope you can help me getting r working. If I can help by
> doing anything,
> | please tell me how...
> | Also, I hope, this is a problem with r and not with my ubuntu, in
> which case I
> | probably wouldn't have contacted you, if I would have known...
> |
> | Thank you very much!
> |
> | All the best,
> | Jakob
> |
> | __
> | R-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Out of bounds negative index
Hi, From the R Language Definition, Section 3.4.1: "If i is positive and exceeds length(x) then the corresponding selection is NA. A negative out of bounds value for i causes an error." (This is also mentioned in S Programming, footnote of page 24.) Can someone please provide an example triggering the error? Looking in src/main/subscript.c I could not find exception handling for |i| > length(x), unless the negative subscript is mixed with NAs. In other cases, out of bounds negative indexes just seem silently ignored. Did I missed or misinterpreted something, here? Thanks in advance --- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Out of bounds negative index
Le ven. 02 mai à 15:46, Duncan Murdoch a écrit : On 5/2/2008 3:23 PM, Vincent Goulet wrote: Hi, From the R Language Definition, Section 3.4.1: "If i is positive and exceeds length(x) then the corresponding selection is NA. A negative out of bounds value for i causes an error." (This is also mentioned in S Programming, footnote of page 24.) Can someone please provide an example triggering the error? Looking in src/main/subscript.c I could not find exception handling for | i| > length(x), unless the negative subscript is mixed with NAs. In other cases, out of bounds negative indexes just seem silently ignored. Did I missed or misinterpreted something, here? Looks to me like a documentation error. I would expect from that description that executing > x <- 1:5 > x[7] [1] NA > x[-7] [1] 1 2 3 4 5 would have given an error on x[-7], but clearly it didn't. This behaviour appears to have started with 2.6.0; 2.5.1 gives the error. I don't see a NEWS entry about it...but revision r42123 says Changed the behaviour of out-of-bounds negative subscripts to match that of S. Such values are now ignored rather than tripping an error. Ah ha, there it is. The svn log is one place I didn't look. I had screened NEWS, ONEWS and OONEWS, though... Thanks, Duncan. so apparently it was intentional. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in polygon.Rd (PR#8605)
Hi, Small typo in the description of argument 'col' of function polygon(): "(For back-compatibiility, ..." should obviously be "(For back-compatibility...". The mistake was still there in 2.3.0 minutes ago... Best, -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] New probability law functions
Dear developers,
I am currently writing, for a package of mine, {d,p,q,r}dist() functions for
some probability laws not already found in base R. I was wondering if the
Core Team would see any interest in having some or all the functions
integrated in base R. I'm talking here of distributions like the Pareto,
Burr, inverted gamma and, ultimately, four parameter transformed beta and
transformed gamma (as named in Klugman, Panjer & Willmot, Loss Models, Second
Edition, Wiley, 2004).
If there is interest, I will gladly contribute patches to relevant files. I'm
asking beforehand since my current implementation is simpler than what is
found in random.c and I would prefer to go one route or another.
Thanks in advance for any feedback.
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Patch to allow negative argument in head() and tail()
Dear developeRs (and other abuseRs ;-), I would like to contribute a patch against functions head() and tail() of package utils to allow for a negative 'n' argument. This allows to extract all but the first/last 'n' elements/rows/lines of an object, similar to the "drop" operator of APL. [1] I put the patched head.R and head.Rd files, along with diff files in http://vgoulet.act.ulaval.ca/pub/R/ The differences were obtained against today's version of r-devel (more specifically revision 30277 of head.R and revision 30915 of head.Rd). Some comments: - The current version of head() and tail() will accept a vector of length > 1 for argument 'n' but will silently use the smallest value. This became awkward to reproduce in my versions and did not seem interesting anyway. Instead, I added an error message if length(n) > 1. - I used the word "scalar" in the aforementioned error message to mean a vector of length 1. Perhaps is this not the correct R terminology? - I added a 'addrownums = TRUE' argument to head() used when n < 0, similar to tail() with n > 0. This required to write separate methods for classes 'data.frame' and 'matrix'. - The 'function' methods are not modified. - In the man page, the 'function' method was not documented in the usage section. Done now. - I don't think the patch would break any existing code, except code using the (undocumented) "feature" mentioned in my first remark, above. I hope you will find my (albeit small) contribution useful. Best regards, - [1] See previous messages to r-devel by myself <https://stat.ethz.ch/pipermail/r-devel/2005-April/032881.html> and Bill Venables <https://stat.ethz.ch/pipermail/r-devel/2005-May/033081.html> -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch to allow negative argument in head() and tail()
Le Mardi 18 Juillet 2006 04:42, Martin Maechler a écrit :
> >>>>> "Vincent" == Vincent Goulet <[EMAIL PROTECTED]>
> >>>>> on Mon, 17 Jul 2006 15:03:34 -0400 writes:
>
> Vincent> Dear developeRs (and other abuseRs ;-),
>
> Vincent> I would like to contribute a patch against
> Vincent> functions head() and tail() of package utils to
> Vincent> allow for a negative 'n' argument. This allows to
> Vincent> extract all but the first/last 'n'
> Vincent> elements/rows/lines of an object, similar to the
> Vincent> "drop" operator of APL. [1]
>
> Hmm, if you reread Bill Venables proposal (URL below), you did
> something different : In Bill's (and my!) "book",
>
> head would always give the *first* few entries and
> tail would always give the *last* few entries.
>
> That's different from APL's drop, but for a good reason:
> The words 'head' and 'tail' exactly suggest so.
Indeed, I did not pay that much attention to the second paragraph.
For me, this usage of head() and tail() is, at first, completely unintuitive
since I more used to, say, "start from the beginning (head) of the vector and
drop the first n elements" than "return the end of the vector except the
first n elements". But I must agree your convention does make sense!
> Vincent> I put the patched head.R and head.Rd files, along with diff
> files in Vincent> http://vgoulet.act.ulaval.ca/pub/R/
>
> Vincent> The differences were obtained against today's version of
> r-devel (more Vincent> specifically revision 30277 of head.R and revision
> 30915 of head.Rd).
>
> That's good (to take the "current" sources for the diffs).
>
> Vincent> Some comments:
>
> Vincent> - The current version of head() and tail() will
> Vincent> accept a vector of length > 1 for argument 'n' but
> Vincent> will silently use the smallest value. This became
> Vincent> awkward to reproduce in my versions and did not
> Vincent> seem interesting anyway. Instead, I added an error
> Vincent> message if length(n) > 1.
>
> that's ok in my view
>
> Vincent> - I used the word "scalar" in the aforementioned
> Vincent> error message to mean a vector of length 1. Perhaps
> Vincent> is this not the correct R terminology?
>
> indeed, it's rarely used in R terminology; for one reason
> because S (and hence R) does not differentiate between length-1
> vectors and scalars the way APL does.
So I should rephrase the message as "n should be a vector of length 1", then.
> Vincent> - I added a 'addrownums = TRUE' argument to head() used when n
> < 0, similar to Vincent> tail() with n > 0. This required to write separate
> methods for Vincent> classes 'data.frame' and 'matrix'.
>
> seems not unreasonable {I did not yet look at your implementation there}
Actually, this will no longer be needed since head() will always return, well,
the head of an object, hence no need to relabel the lines of a matrix.
> Vincent> - The 'function' methods are not modified.
>
> Vincent> - In the man page, the 'function' method was not documented in
> the usage Vincent> section. Done now.
>
> ok, though not necessary: The recommended approach is to only
>document methods when they have ``surprising arguments'', i.e.,
>arguments not in the generic function.
>
> In our case, 'n = 6' is not part of the generic, so strictly
> speaking *is* a "surprising argument".
> Probably it was not made part of the generic, since it's
> imaginable to have objects whose "head" is always of a fixed
> given size, and where specifying 'n' does not make sense.
>
> Vincent> - I don't think the patch would break any existing code,
> except code using the Vincent> (undocumented) "feature" mentioned in my
> first remark, above.
>
> Vincent> I hope you will find my (albeit small) contribution useful.
>
> Yes, but can you change it such that head() does give the "head"
> and tail() the "tail" also for negative 'n' ?
I'll give it a go in the next couple of days.
Bye!Vincent
> Vincent> Best regards,
>
> Bonnes salutations,
> Martin
>
> Vincent> -
> Vincent> [1] See previous messages to r-devel by myself
> Vincent>
> <https://stat.ethz.ch/pipermail/r-devel/2005-April/032881.html>
>
> Vincent> and Bill Venables
> Vincent> <https://stat.ethz.ch/pipermail/r-devel/2005-May/033081.html>
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Patch to allow negative argument in head() and tail()
Le Mardi 18 Juillet 2006 04:42, Martin Maechler a écrit :
> >>>>> "Vincent" == Vincent Goulet <[EMAIL PROTECTED]>
> >>>>> on Mon, 17 Jul 2006 15:03:34 -0400 writes:
>
> Vincent> Dear developeRs (and other abuseRs ;-),
>
> Vincent> I would like to contribute a patch against
> Vincent> functions head() and tail() of package utils to
> Vincent> allow for a negative 'n' argument. This allows to
> Vincent> extract all but the first/last 'n'
> Vincent> elements/rows/lines of an object, similar to the
> Vincent> "drop" operator of APL. [1]
>
> Hmm, if you reread Bill Venables proposal (URL below), you did
> something different : In Bill's (and my!) "book",
>
> head would always give the *first* few entries and
> tail would always give the *last* few entries.
>
> That's different from APL's drop, but for a good reason:
> The words 'head' and 'tail' exactly suggest so.
I modified my patch to go along these lines. My brain must be wired
differently since it remains counter intuitive to me but then, who am I to go
against R Core Team members and Unix itself! ;-)
> Vincent> I put the patched head.R and head.Rd files, along with diff
> files in Vincent> http://vgoulet.act.ulaval.ca/pub/R/
>
> Vincent> The differences were obtained against today's version of
> r-devel (more Vincent> specifically revision 30277 of head.R and revision
> 30915 of head.Rd).
>
> That's good (to take the "current" sources for the diffs).
This time I just attached the result of 'svn diff' against revision 38701 of
r-devel.
Please note that in head.default() and tail.default() I deleted the line
if(length(dim(x)) == 1) array(ans, n, list(names(ans))) else ans
since I could not find any use for it. Perhaps did this become obsolete with
the following bug fix in v2.2.0 (from the release notes):
o Subsetting a matrix or an array as a vector used to attempt to
use the row names to name the result, even though the
array might be longer than the row names. Now this is only
done for 1D arrays when it is done in all cases, even matrix
indexing. (Tidies up after the fix to PR#937.)
But then, even in 2.1.1:
> x <- array(1:10, 10, list(letters[1:10]))
> x
a b c d e f g h i j
1 2 3 4 5 6 7 8 9 10
> x[1:3]
a b c
1 2 3
> identical(x[1:3], array(x[1:3], 3, list(names(x[1:3]
[1] TRUE
If the deleted line should remain, please (explain why and) tell me and I'll
add it back.
> Vincent> Some comments:
>
> Vincent> - The current version of head() and tail() will
> Vincent> accept a vector of length > 1 for argument 'n' but
> Vincent> will silently use the smallest value. This became
> Vincent> awkward to reproduce in my versions and did not
> Vincent> seem interesting anyway. Instead, I added an error
> Vincent> message if length(n) > 1.
>
> that's ok in my view
Still there.
> Vincent> - I used the word "scalar" in the aforementioned
> Vincent> error message to mean a vector of length 1. Perhaps
> Vincent> is this not the correct R terminology?
>
> indeed, it's rarely used in R terminology; for one reason
> because S (and hence R) does not differentiate between length-1
> vectors and scalars the way APL does.
Changed for "single integer", as found in another help page.
> Vincent> - I added a 'addrownums = TRUE' argument to head() used when n
> < 0, similar to Vincent> tail() with n > 0. This required to write separate
> methods for Vincent> classes 'data.frame' and 'matrix'.
>
> seems not unreasonable {I did not yet look at your implementation there}
As mentioned in another message, this is no longer needed.
> Vincent> - The 'function' methods are not modified.
>
> Vincent> - In the man page, the 'function' method was not documented in
> the usage Vincent> section. Done now.
>
> ok, though not necessary: The recommended approach is to only
>document methods when they have ``surprising arguments'', i.e.,
>arguments not in the generic function.
>
> In our case, 'n = 6' is not part of the generic, so strictly
> speaking *is* a "surprising argument".
> Probably it was not made part of the generic, since it's
> imaginable to have objects whose "head" is always of a fixed
> given size, and where specifying 'n' does not make sense.
For symmetry, I think it should be added.
> Vincent> - I don't think the patch would break any existing code,
> except code using the Vincent> (undocumented) "feature" mentioned in my
> first remark, above.
This should remain valid.
[...]
Best regards to all,
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] building windows packages under wine/linux an d cross-compiling.
Le Mercredi 2 Août 2006 21:33, Duncan Murdoch a écrit : > On 8/2/2006 6:05 PM, Hin-Tak Leung wrote: > > Uwe Ligges wrote: > > > > > >> I cannot imagine: Why should one want to perform difficult cross > >> compiling if you have Windows available? > >> And why should I run R under wine? If I like Windows, I use Windows, if > >> I have like Linux, there is no reason to run R under wine. > > > > *You* cannot imagine. > > > > I am an almost exlusively linux person. An acquitance, also a > > mainly linux person, for teaching purpose, asked for windows binary > > of something I (co-)wrote, to be installed on to the teaching machines. > > Installing too many development tools on teaching machines is not > > an option; so the other option, than cross-compiling, is to > > *borrow* a windows machine *set up for development purposes*. > > (which I did, at the start). > > > > I cannot, and would not, keep on repeatedly borrowing other > > people's windows development machines, which they have possibly > > spent some time in setting up; besides, they may not have all > > the tools, and/or willing to put things like Mingw or ActiveState > > Perl on their machines. I did have to install both, plus the > > latest version of R - in my first native try, and immediately > > de-installing them from the borrowed machine as soon as I finished. > > > > You are not involved in any teaching roles, I reckon? And you haven't > > written any packages that you would like others to use, on a > > different platform from your own? > > > > Since I am cross-compiling, it goes that I would like to test > > the result of cross-compiling right-away under wine, without > > switching machine or rebooting (in case of dual boot). In fact I > > found and fix a bug in my code, which *only* shows up under > > wine's implementation of msvcrt, not on win2k's or glibc's - wine's > > msvcrt behavior is valid ANSI C, but different from MS win2k > > or linux glibc's. (and nobody can say for sure win2k's msvcrt is > > exactly the same as NT, XP, etc's). > > What I'd recommend you do is get an old laptop with Windows installed on > it, and install the development tools there. There are probably several > lying around peoples' offices in your department. If you found bugs in > your code because of differences between wine and Windows, you're also > bound to find bugs in wine, and waste a lot of time trying to see what's > wrong with your code when really there's nothing at all wrong with it. > > You'll also soon find people complaining that your package doesn't > contain compiled HTML help, because there's no Linux tool to build that. > > Windows machines are cheap. You don't need a new one to build a package > or to run R. I can't imagine there is any change to the build procedure > that would cost less in our time than the cost to you of getting an old > Windows box. > > Duncan Murdoch I already wrote this to Hin-Tak privately but will repeat it here "for the record": use VMWare for Windows development on a Linux host (or the other way around, or any other combination for that matter). The Server version is now free. It's a great product. No need to reboot or to have a separate computer. A virtual one (or two, or...) is right there on your desktop. HTH -- Vincent Goulet, Professeur agrégé École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S3 methods for cbind/rbind
I created a type of object similar to a data frame. In some circumstances, It needs special methods for "[" and "[<-" and rbind() (but not cbind()). Then I found this in the cbind()/rbind() man page: The method dispatching is _not_ done via 'UseMethod()', but by C-internal dispatching. Therefore, there is no need for, e.g., 'rbind.default'. This seems to imply I cannot add my own method. Is there 1) a workaround to and 2) a rationale for this? (Other than creating a generic Rbind() or whatever, that is.) I'm using S3 methods. Thanks in advance! -- Vincent Goulet, Associate Professor École d'actuariat Université Laval, Québec [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S3 methods for cbind/rbind
Hum. Then, I need to be more accurate. My object is of class
c("bar", "data.frame"). So, by virtue of ...
The dispatch algorithm is described in the source file
('.../src/main/bind.c') as
1. For each argument we get the list of possible class
memberships from the class attribute.
2. We inspect each class in turn to see if there is an an
applicable method.
... rbind(foo) is never sent to rbind.bar(). So I guess my questions stand.
Le Mercredi 27 Septembre 2006 16:16, Gabor Grothendieck a écrit :
> Actually you can add your own method. See
>
> library(zoo)
> rbind.zoo
>
> for an example.
>
> On 9/27/06, Vincent Goulet <[EMAIL PROTECTED]> wrote:
> > I created a type of object similar to a data frame. In some
> > circumstances, It needs special methods for "[" and "[<-" and rbind()
> > (but not cbind()). Then I found this in the cbind()/rbind() man page:
> >
> > The method dispatching is _not_ done via 'UseMethod()', but by
> > C-internal dispatching. Therefore, there is no need for, e.g.,
> > 'rbind.default'.
> >
> > This seems to imply I cannot add my own method. Is there 1) a workaround
> > to and 2) a rationale for this? (Other than creating a generic Rbind() or
> > whatever, that is.)
> >
> > I'm using S3 methods.
> >
> > Thanks in advance!
> >
> > --
> > Vincent Goulet, Associate Professor
> > École d'actuariat
> > Université Laval, Québec
> > [EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
--
Vincent Goulet, Associate Professor
École d'actuariat
Université Laval, Québec
[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "R CMD Sweave --driver=..." woes
In trying to change the driver used by Sweave on the command line using
R CMD Sweave --driver=foo
I consistently get the "directory 'foo' does not exist' error. (For any value
of 'foo', even the default 'RweaveLatex'.)
Looking up the source code for function .Sweave that is called by 'R CMD
Sweave', I notice that the argument 'driver', if used, is added to the vector
of arguments of ''buildVignette' without being named. It ends up being passed
to argument 'dir', hence rhe error.
I believe the simple patch below should fix the issue, but I wasn't able to
test it.
Hope this helps.
v.
Vincent Goulet
Professeur titulaire
École d'actuariat, Université Laval
Index: src/library/utils/R/Sweave.R
===
--- src/library/utils/R/Sweave.R(revision 78746)
+++ src/library/utils/R/Sweave.R(working copy)
@@ -516,7 +516,7 @@
do_exit(1L)
}
args <- list(file=file, tangle=FALSE, latex=toPDF, engine=engine,
clean=clean)
-if(nzchar(driver)) args <- c(args, driver)
+if(nzchar(driver)) args <- c(args, driver=driver)
args <- c(args, encoding = encoding)
if(nzchar(options)) {
opts <- eval(str2expression(paste0("list(", options, ")")))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Adding RtangleRuncode and RtangleFinish to exports of utils
Hi,
Could R-Core consider adding 'RtangleRuncode' and 'RtangleFinish' to the
exports of utils. Their weave equivalent 'makeRweaveLatexCodeRunner' and
'RweaveLatexFinish' are exported, as well as the other tangle utility
functions 'RtangleSetup' and 'RtangleWritedoc'.
The rationale is not just symmetry. ;-)
I'm finishing a small package that will provide "enhanced" drivers for Sweave
that are heavily based on the standard RweaveLatex and Rtangle drivers. So much
so that I can reuse most of the utiity functions called by RweaveLatex() and
Rtangle(). Now, 'RtangleRuncode' and 'RtangleFinish' are not exported and 'R
CMD check' really does not like that I use the ::: operator to reach the
functions.
The alternative is to duplicate the code verbatim in my package. This does not
seem very sensible, especially since I would then need to track any changes to
the aforementioned functions to remain in line.
Here is the proposed patch against the current r-devel tree:
Index: src/library/utils/NAMESPACE
===
--- src/library/utils/NAMESPACE (revision 78794)
+++ src/library/utils/NAMESPACE (working copy)
@@ -166,9 +166,9 @@
Sweave, SweaveSyntConv, SweaveSyntaxLatex, SweaveSyntaxNoweb,
RtangleWritedoc, RweaveChunkPrefix, RweaveEvalWithOpt,
RweaveTryStop, SweaveHooks, RweaveLatexWritedoc,
- RweaveLatexOptions, RweaveLatexFinish,
+ RweaveLatexOptions, RweaveLatexFinish, RtangleFinish,
.RtangleCodeLabel,
- makeRweaveLatexCodeRunner)
+ makeRweaveLatexCodeRunner, RtangleRuncode)
if(tools:::.OStype() == "unix") {
export(nsl)
Best,
v.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in Writing R Extensions
Hi, Just noticed this: on line 15296 of the current (master) R-exts.texi (section 7 of the compiled document), one reads would do most likely do different things, to the justifiable Either one of the "do" is in extra. Best, Vincent Goulet Université Laval __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small typo in ?NumericConstants
Hi,
I stumbled upon this small typo in ?base::NumericConstants:
Index: library/base/man/NumericConstants.Rd
===
--- library/base/man/NumericConstants.Rd(révision 80490)
+++ library/base/man/NumericConstants.Rd(copie de travail)
@@ -47,7 +47,7 @@
A numeric constant immediately followed by \code{i} is regarded as an
imaginary \link{complex} number.
- An numeric constant immediately followed by \code{L} is regarded as an
+ A numeric constant immediately followed by \code{L} is regarded as an
\code{\link{integer}} number when possible (and with a warning if it
contains a \code{"."}).
Best,
v.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
