Re: [Rd] Compiling R scripts
Uzuner, Tolga wrote: > Dear R Developers, > It would help if R scripts could be compiled into an executable, or a > library. Are you sure it would help? If you do a big matrix operation in R it runs at the speed of the underlying C code. It wont get much faster. Profile your code, find out where the time is being spent, then optimise _that_. > Speed is the main issue (I run a large scale monte carlo in > R which is very slow). The reason its very slow is not because its 'in R' but because it is a 'large scale monte carlo'. What was a 'large scale' monte-carlo ten years ago runs in no time today. 'large scale' == 'slow' almost by definition. Unless you've done comparisons with the same code written in some other language. > However, it would also make it easier to link > R into other applications, easier at least than the COM > infrastructure under Windows. R can be called from C, and there are application links to Python, Perl, Java... Easy enough. > Finally, it would make it much easier to farm R apps: rather than > distributing all of R and necessary libraries onto each client, and > making sure each client is always up to date as libraries for a > specific script change, it might be easier just to distribute a > simple executable across all nodes. Keeping a bunch of clients up to date is as easy as a quick scripted rsync command, or completely transparent if you have a shared /usr/local filesystem (Unix). There is some work going on to produce an R compiler, but I dont think these are the reasons. Baz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date() , feature or bug?
Prof Brian Ripley wrote: > > What does anyone want such dates for? I hope there was an extremely good > reason to spend other people's time on this, and look forward to an > extremely convincing explanation. > I can think of one case where I've seen exact dates that far in the future used: astronomical calculations. You may have something like "And the next chance you'll get to see Jupiter this close to Venus will be on December 12th 8766CE. Just after lunchtime in whatever remains of London then.". Is there an R package for astronomical calculations? Baz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes for large formulas in lm() (PR#8180)
Prof Brian Ripley wrote: > OK, let's try to reproduce that: > > >>x1 <- runif(1000) ... >>y <- rnorm(1000) >>fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) > > > No crash, a quite reasonable fit. Add one more: > x9 <- runif(1000) works with 8: > fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) but go 'one over the eight' and: > fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8*x9)^2) Segmentation fault platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major2 minor1.1 year 2005 month06 day 20 language R Baz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes for large formulas in lm() (PR#8180)
> set.seed(123) > x1 <- runif(1000) > x2 <- runif(1000) > x3 <- runif(1000) > x4 <- runif(1000) > x5 <- runif(1000) > x6 <- runif(1000) > x7 <- runif(1000) > x8 <- runif(1000) > y <- rnorm(1000) > fit <- lm(y~(x1*x2*x3*x4*x5*x6*x7*x8)^2) For me (with 9 variables) this crashes in model.matrix: > f1=y~(x1*x2*x3*x4*x5*x6*x7*x8*x9)^2 > model.matrix(f1) Segmentation fault I guess someone with a debug-compiled R can get a bit further... Baz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] image() with all NAs fails (PR#8228)
Full_Name: Barry Rowlingson Version: 2.2.0 OS: Linux Submission from: (NULL) (194.80.32.8) The image function with a matrix of all NA values fails with: > xyz=list(x=1:3,y=1:4,z=matrix(NA,3,4)) > image(xyz) Error in image.default(xyz) : invalid z limits In addition: Warning messages: 1: no finite arguments to min; returning Inf 2: no finite arguments to max; returning -Inf Image can handle any number of NAs as long as there is at least one data value: > xyz=list(x=1:3,y=1:4,z=matrix(c(1,rep(NA,11)),3,4)) > image(xyz) and shows NAs as transparent. However if it is all NAs then the z-limit calculation breaks down as above. It seems reasonable to me that image() with all NAs should produce a completely transparent/empty image (after displaying the axes if add!=TRUE) and not fail with an error. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] two-way communication using Unix pipes
Jonathan Callahan wrote:
> Can someone please explain to me exactly what R is doing with the the
> standard IO handles and whether or not there is any simple way to convince
> it to behave as if it were talking to a user at the other end of a keyboard
> and terminal? I've already tried '--no-readline' but that doesn't solve my
> problem.
>
This little noddy example works for me:
#!/usr/bin/perl
use FileHandle;
use IPC::Open2;
$pid=open2(*Reader, *Writer, "R --no-save");
print Writer "x=runif(10);print(mean(x))\n";
while($got=){
print "Got ".$got;
}
Of course, without the \n in the command string it doesnt work at all,
but I dont see any problems with R reading from stdin and writing to
stdout
This is on a Linux box, I dont think you mentioned an OS or platform...
Baz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] checkpointing
Roger D. Peng wrote: > One possibility is to write in some checkpointing into your objective > function, > such as saving the current parameter values via 'save()' or 'dput()'. Has anyone successfully checkpointed and restarted R using any of the linux process checkpointing solutions I find when I google for 'linux process checkpointing'? I cant see why you'd bother implementing checkpointing within optim() if you can do it at the process level and hence in the middle of anything. Unless you're running Windows. An example and some links here: http://www.cise.ufl.edu/~mfoster/research/uclik/uclik.htm Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R on Thin Client with Win 2003
I'm having some fun with R on a Windows 2003 Server talking to a Wyse Winterm running Thinstation Linux. The Winterm boots Linux from the network and then runs rdesktop to a Dell 1750 server (dual 3G Xeon or somesuch). The first problem I noticed was that R (and the terminal) ground to a near halt during demo(graphics). Further investigation showed that it seemed to be due to having par(ask=TRUE) set. So: par(ask=TRUE);plot(1:10);plot(1:10) would cause the Windows session to become unresponsive. Usually it would recover, but sometimes not. This was odd, because I have had a similar setup servicing a lab for over a year without problems. Similar, except this old lab has R 1.9.1 installed and not shiny new 2.2.1. So I installed R 1.9.1 on the new server - and then there's no problem with par(ask=TRUE) stuff. Further R installs show the problem manifests itself in 2.1.1 and not 2.0.1, coincidental with a change in the prompt from "Hit to see next plot" (2.0.1) to "Click or hit ENTER for next page" (2.1.1). Curious... Running rdesktop from my desktop Linux box and connecting to the same server doesn't show any of these problems. So I can't blame the network. Possible reasons for the change: * Difference in rdesktop versions (1.4.1 on Wyse, 1.3 on my machine) * Difference in X version (Xorg 6.9.0 on Wyse, XFree86 4.2.1 on mine) I think the next thing to try is to put R 2.2.1 on the old lab and see how that copes. Has anyone else any experience running R from Win2003 servers or on Wyse Winterm X-terminals or using Thinstation Linux? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why R should never move to git
On Tue, Jan 30, 2018 at 11:07 PM, Suzen, Mehmet wrote: > This might be off topic, but if R-core development ever moves to git, > I think it would make sense to have its own git service hosted by a > university, rather than using > github or gitlab. It is possible via https://gogs.io/ project. > > Just for the record. > > Let the record also state that *gitlab* is an open source project and can be downloaded and self-hosted, like gogs, but unlike github. Barry PS I've been running a gitlab instance for my group for a couple of years on a private server. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] base::mean not consistent about NA/NaN
And for a starker example of this (documented) inconsistency, arithmetic addition is not commutative: > NA + NaN [1] NA > NaN + NA [1] NaN On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch wrote: > On 02/07/2018 11:25 AM, Jan Gorecki wrote: >> Hi, >> base::mean is not consistent in terms of handling NA/NaN. >> Mean should not depend on order of its arguments while currently it is. > > The result of mean() can depend on the order even with regular numbers. > For example, > > > x <- rep(c(1, 10^(-15)), 100) > > mean(sort(x)) - 0.5 > [1] 5.551115e-16 > > mean(rev(sort(x))) - 0.5 > [1] 0 > > >> >> mean(c(NA, NaN)) >> #[1] NA >> mean(c(NaN, NA)) >> #[1] NaN >> >> I created issue so in case of no replies here status of it can be looked up >> at: >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 > > The help page for ?NaN says, > > "Computations involving NaN will return NaN or perhaps NA: which of > those two is not guaranteed and may depend on the R platform (since > compilers may re-order computations)." > > And ?NA says, > > "Numerical computations using NA will normally result in NA: a possible > exception is where NaN is also involved, in which case either might > result (which may depend on the R platform). " > > So I doubt if this inconsistency will be fixed. > > Duncan Murdoch > >> >> Best, >> Jan >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] base::mean not consistent about NA/NaN
On Tue, Jul 3, 2018 at 10:12 AM, Jan Gorecki wrote: > Thank you for interesting examples. > I would find useful to document this behavior also in `?mean`, while `+` > operator is also affected, the `sum` function is not. `sum` is "affected" on my system, if you mean: > sum(c(NA,NaN)) [1] NA > sum(c(NaN,NA)) [1] NaN oh, maybe you mean: > sum(NaN, NA) [1] NA > sum(NA, NaN) [1] NA But whatever, no money back guarantee: Computations involving ‘NaN’ will return ‘NaN’ or perhaps ‘NA’: which of those two is not guaranteed and may depend on the R platform (since compilers may re-order computations). > For mean, NA / NaN could be handled in loop in summary.c. I assume that > performance penalty of fix is the reason why this inconsistency still > exists. > Jan > > On Mon, Jul 2, 2018 at 8:28 PM, Barry Rowlingson > wrote: >> >> And for a starker example of this (documented) inconsistency, >> arithmetic addition is not commutative: >> >> > NA + NaN >> [1] NA >> > NaN + NA >> [1] NaN >> >> >> >> On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch >> wrote: >> > On 02/07/2018 11:25 AM, Jan Gorecki wrote: >> >> Hi, >> >> base::mean is not consistent in terms of handling NA/NaN. >> >> Mean should not depend on order of its arguments while currently it is. >> > >> > The result of mean() can depend on the order even with regular numbers. >> > For example, >> > >> > > x <- rep(c(1, 10^(-15)), 100) >> > > mean(sort(x)) - 0.5 >> > [1] 5.551115e-16 >> > > mean(rev(sort(x))) - 0.5 >> > [1] 0 >> > >> > >> >> >> >> mean(c(NA, NaN)) >> >> #[1] NA >> >> mean(c(NaN, NA)) >> >> #[1] NaN >> >> >> >> I created issue so in case of no replies here status of it can be >> >> looked up >> >> at: >> >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 >> > >> > The help page for ?NaN says, >> > >> > "Computations involving NaN will return NaN or perhaps NA: which of >> > those two is not guaranteed and may depend on the R platform (since >> > compilers may re-order computations)." >> > >> > And ?NA says, >> > >> > "Numerical computations using NA will normally result in NA: a possible >> > exception is where NaN is also involved, in which case either might >> > result (which may depend on the R platform). " >> > >> > So I doubt if this inconsistency will be fixed. >> > >> > Duncan Murdoch >> > >> >> >> >> Best, >> >> Jan >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> __ >> >> R-devel@r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> >> > >> > __ >> > R-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug: R --slave --interactive stdin echo on Linux when stdin is a fifo
On Thu, Jul 26, 2018 at 12:22 AM, Gábor Csárdi wrote: > I am trying to control a background R session, connected via a fifo / > named pipe. Is the fifo significant here? If I read the same R code from a file via `<` I get the input echoed (R 3.4.4, Ubuntu). Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] diag(-1) produces weird result
On Mon, Sep 17, 2018 at 5:22 PM, Gábor Csárdi wrote: > I would say it is a mis-feature. If the 'x' argument of diag() is a > vector of length 1, then it creates an identity matrix of that size, > instead of creating a 1x1 matrix with the given value: > > ❯ diag(3) > [,1] [,2] [,3] > [1,]100 > [2,]010 > [3,]001 > > Of course this makes it cumbersome to use diag() in a package, when > you are not sure if the input vector is longer than 1. This seems to > be a good workaround: > > ❯ diag(-1, nrow = 1) > [,1] > [1,] -1 > > Or, in general if you have vector v: > > ❯ v <- -1 > ❯ diag(v, nrow = length(v)) > [,1] > [1,] -1 > > > Anyone else getting deja-vu with the `sample` function? > sample(5:3) [1] 3 5 4 ok... > sample(5:4) [1] 4 5 fine... > sample(5:5) [1] 3 1 5 2 4 uh oh. Documented, of course. B [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sys.call() inside replacement functions incorrectly returns *tmp*
On Tue, Oct 16, 2018 at 12:03 AM Abs Spurdle wrote: > Probably the best example I can think of is converting cartesian > coordinates to polar coordinates. > Then we might have something like (note, untested, written in my email): > cart2polar = function (x, y) > list (theta=atan (y / x), r=sqrt (x * x + y * y) ) > > massign (r, theta) = cart2polar (x, y) > > Now, I'm considering a multiple assignment operator, so something like: > c (theta, r) $<-$ cart2polar (x, y) This is something that comes up occasionally and as noted by Gabor, has been implemented in packages. But I am not keen on unpacking the return from a function into multiple objects. The reason your `cart2polar` function returns a list of theta and r is because it is returning a polar coordinate, and that coordinate needs both. Why unpack them? If you don't need theta, then do `r = cart2polar(x,y)$r`. If you need theta and r, then keep them together in a single object. If you need to call a function that needs separate theta and r, use `plot(d$r, d$theta)`. Its a bit more typing but that's a false efficiency when you want code to be tidy and well-structured, and to convey meaning. `plot(this$r, this$theta)` is clearly a plot of something to do with `this`, and you can see that the r and the theta are coming from the same thing, whereas a `(r,theta) %=% foo(x,y)` some place and then `plot(r, theta)` somewhere else has broken the connection. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
On Thu, Jan 31, 2019 at 3:14 PM David Lindelof wrote: > > In summary, I'm convinced R would benefit from something similar to Java's > `Main-Class` header or Python's `__main__()` function. A new R CMD command > would take a package, install its dependencies, and run its "main" > function. I just created and built a very boilerplate R package called "runme". I can install its dependencies and run its "main" function with: $ R CMD INSTALL runme_0.0.0.9000.tar.gz $ R -e 'runme::main()' No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with python and java and C the entrypoint is more tightly specified (__name__ == "__main__" in python, int main(..) in C and so on). But I don't think that's much of a problem. Does that not satisfy your requirements close enough? If you want it in one line then: R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' will do the second if the first succeeds (Unix shells). You could write a script for $RHOME/bin/RUN which would be a two-liner and that could mandate the use of "main" as an entry point. But good luck getting anything into base R. Barry > If we have this machinery available, we could even consider > reaching out to Spark (and other tech stacks) developers and make it easier > to develop R applications for those platforms. > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
Ummm oops. Magic pixies? It assumed all of CRAN was installed? Maybe I'll write something that could go in /usr/lib/R/bin/RUN that checks and gets deps, installs the package, and runs package::main, which I think is what the OP wants - you could do R CMD RUN foo_1.0.0.tar.gz and away it goes... B On Thu, Jan 31, 2019 at 3:56 PM David Lindelof wrote: > > Would you care to share how your package installs its own dependencies? I > assume this is done during the call to `main()`? (Last time I checked, R CMD > INSTALL would not install a package's dependencies...) > > > On Thu, Jan 31, 2019 at 4:38 PM Barry Rowlingson > wrote: >> >> >> >> On Thu, Jan 31, 2019 at 3:14 PM David Lindelof wrote: >>> >>> >>> In summary, I'm convinced R would benefit from something similar to Java's >>> `Main-Class` header or Python's `__main__()` function. A new R CMD command >>> would take a package, install its dependencies, and run its "main" >>> function. >> >> >> >> I just created and built a very boilerplate R package called "runme". I can >> install its dependencies and run its "main" function with: >> >> $ R CMD INSTALL runme_0.0.0.9000.tar.gz >> $ R -e 'runme::main()' >> >> No new R CMDs needed. Now my choice of "main" is arbitrary, whereas with >> python and java and C the entrypoint is more tightly specified (__name__ == >> "__main__" in python, int main(..) in C and so on). But I don't think that's >> much of a problem. >> >> Does that not satisfy your requirements close enough? If you want it in one >> line then: >> >> R CMD INSTALL runme_0.0.0.9000.tar.gz && R -e 'runme::main()' >> >> will do the second if the first succeeds (Unix shells). >> >> You could write a script for $RHOME/bin/RUN which would be a two-liner and >> that could mandate the use of "main" as an entry point. But good luck >> getting anything into base R. >> >> Barry >> >> >> >>> >>> If we have this machinery available, we could even consider >>> reaching out to Spark (and other tech stacks) developers and make it easier >>> to develop R applications for those platforms. >>> >> >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Runnable R packages
I don't think anyone denies that you *could* make an EXE to do all that. The discussion is on *how easy* it should be to create a single file that contains an initial "main" function plus a set of bundled code (potentially as a package) and which when run will install its package code (which is contained in itself, its not in a repo), install dependencies, and run the main() function. Now, I could build a self-executable shar file that bundled a package together with a script to do all the above. But if there was a "RUN" command in R, and a convention that a function called "foo::main" would be run by `R CMD RUN foo_1.1.1.tar.gz` then it would be so much easier to develop and test. If people think this adds value, then if they want to offer that value to me as $ or £, I'd consider writing it if their total value was more than my cost Barry On Sat, Feb 2, 2019 at 12:54 AM Abs Spurdle wrote: > > Further to my previous post, > it would be possible to create an .exe file, say: > > my_r_application.exe > > That starts R, loads your R package(s), calls the R function of your choice > and does whatever else you want. > > However, I don't think that it would add much value. > But feel free to correct me if you think that I'm wrong. > > [[alternative HTML version deleted]] > > __ > 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] bugs in head() and tail()
On Wed, Mar 27, 2019 at 1:52 AM Abs Spurdle wrote: > > In the case of head.default(), it assumes that the object is a vector, or > something similar. > No it doesn't. It assumes (ultimately) that x[seq_len(n)] is the correct way to generate a "head" of something. Which is reasonable. That's dependent on the implementation of the `[` method on object `x`. > Resulting in the error above, which fails to recognize that the input was > unsuitable. > > Because the object you fed it didn't have a method for `head` or for `[`. Its the object designer's responsibility to do that. And by creating a function that doesn't have the "function" class - that means *you*. There's no way that head.default can inspect everything it might get fed, including classes that have yet to be made, to see if it can do anything meaningful with it. So it uses what looks like a reasonable approach - apply `[` on the object with the first `n` elements. Let the class decide what to do with it. You might think generics should trap errors and give meaningful errors, but the error isn't in the generic here - its in the `[` method of the class it was fed. `head` doesn't know or care about that - again, its the class designers responsibility to handle that, and the users responsibility to *not* call generics on objects for which there's no meaningful behaviour. It's really the error message of `[.default` seeming obscure to you that is your issue here. If it said "cannot create subsets of this object with [" would that please you? Again, that's not a bug in `head` or anything to do with method dispatch. So lets take a look at your choices here: "If a generic has a default method, then that default method should be guaranteed to work." - as demonstrated, the default here does its job. it does "work". "Or at least, provide a useful error message, that makes it obvious to the user, what he or she has done wrong." and that error message is the responsibility of methods of the object, in this case `[`. therefore its not a bug. Barry > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Making R CMD nicer
If you write a lot of R code to run as command line scripts then look at Dirk E's "littler": $ r --help Usage: r [options] [-|file] Launch GNU R to execute the R commands supplied in the specified file, or from stdin if '-' is used. Suitable for so-called shebang '#!/'-line scripts. Options: -h, --help Give this help list --usage Give a short usage message -V, --versionShow the version number -v, --vanillaPass the '--vanilla' option to R -t, --rtemp Use per-session temporary directory as R does -i, --interactiveLet interactive() return 'true' rather than 'false' -q, --quick Skip autoload / delayed assign of default libraries -p, --verbosePrint the value of expressions to the console -l, --packages list Load the R packages from the comma-separated 'list' -d, --datastdin Prepend command to load 'X' as csv from stdin -L, --libpath dirAdd directory to library path via '.libPaths(dir)' -e, --eval expr Let R evaluate 'expr' available from an archive near you... On Mon, Jul 1, 2019 at 8:58 AM Jason Xu wrote: > In my humble personal opinion, I try to avoid bash scripts longer than a > couple lines because I find the syntax so obtuse and unintuitive it's > difficult to maintain and write less buggy code. But that is mostly a > reflection of my personal inexperience. > I think the only time a bash script is really needed is for maximum > portability in systems _with bash_. > (I would use python for a wrapper in personal projects, given python comes > pre-installed on many linux systems and OS X, but I completely understand > not wanting to burden Windows users with an extra python dependency to > install.) > > > > > > On Sun, Jun 30, 2019 at 8:08 PM Abby Spurdle wrote: > > > In that case, I was wrong. > > And I must apologize... > > > > In saying that, good to see Windows out performing Linux on the command > > line... > > > > > > On Mon, Jul 1, 2019 at 11:30 AM Gábor Csárdi > > wrote: > > > > > > For the record, this is Linux R-devel: > > > > > > root@4bef68c16864:~# R CMD > > > /opt/R-devel/lib/R/bin/Rcmd: 60: shift: can't shift that many > > > root@4bef68c16864:~# R CMD -h > > > /opt/R-devel/lib/R/bin/Rcmd: 62: exec: -h: not found > > > root@4bef68c16864:~# R CMD --help > > > /opt/R-devel/lib/R/bin/Rcmd: 62: exec: --help: not found > > > > > > This is R-release on macOS: > > > > > > ❯ R CMD > > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: > > > /Library/Frameworks/R.framework/Resources/bin/: is a directory > > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: > > > /Library/Frameworks/R.framework/Resources/bin/: cannot execute: > > > Undefined error: 0 > > > ❯ R CMD -h > > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: -h: > > > invalid option > > > exec: usage: exec [-cl] [-a name] file [redirection ...] > > > ❯ R CMD --help > > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: --: > > > invalid option > > > exec: usage: exec [-cl] [-a name] file [redirection ...] > > > > > > On Windows you indeed get a useful list of commands and more helpful > > tips. > > > > > > Gabor > > > > > > > > > On Sun, Jun 30, 2019 at 11:36 PM Abby Spurdle > > wrote: > > > > > > > > > First time posting in the R mailing lists so hopefully this works > > well. > > > > > I noticed when I type `R CMD` I get this unhelpful message: > > > > > /usr/lib/R/bin/Rcmd: 60: shift: can't shift that many > > > > > > > > I wasn't able to reproduce this. > > > > Maybe it's a Linux thing. > > > > But then, I suspect you've omitted some of your input. > > > > > > > > > I also think it would be nice if `R CMD help` showed the usable > > commands. > > > > > > > > What do you mean... > > > > All of the following give you the "usable commands": > > > > > > > > > R CMD > > > > > R CMD -h > > > > > R CMD --help > > > > > > > > [[alternative HTML version deleted]] > > > > > > > > __ > > > > R-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defining a method that behaves like '$'?
On Fri, Jul 9, 2010 at 2:10 PM, Renaud Gaujoux wrote: > I do not want to access the slot itself but its content: a:toto would be > a...@slot1[['toto']]. > The thing is that I would like to have two different methods: '$' (that I > already have) and another one to define, ideally that behaves like '$'. > So in brief: > - a:toto would be for a...@slot1[['toto']] > - a$tata would be for a...@slot2[['tata']] > > But apparently it might not be possible. > Even if possible, definitely not desirable. As already mentioned, a:b is the sequence a to b (as in 0:10), so it's going to look weird to anyone who hasn't noticed your definition. Also, it looks fairly meaningless. By which I mean there's no obvious reason why a colon should do what you want it to do. There's also no obvious reason why a dollar sign does what it does (whats it got to do with dollars?) but we've had it for 20 years so we're stuck with it. Write a method for your objects and force your users to do a bit more typing as a trade-off for legibility: slot1(a,"toto") is a lot more readable than a:toto (assuming you replace 'slot1' with something meaningful). Remember, code is most likely to be written once, and read many times - so make it easy for readers! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
On Sat, Aug 21, 2010 at 4:41 PM, Donald Winston wrote: > Who decides what features are in R and how they are implemented? If there is > someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some auxiliary > package, but part of the core R just like plot(). As a long time SAS user I > cannot believe R does not have this. Please don't give me any crap about > Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll > your own" plot do you? Reports are no different. If you don't agree do not > bother me. If you agree then please bring this request to the appropriate > authorities for consideration or tell me how to do it. Okay Donald, let's do this. Together. Because only you seem to know what you want in this report() function. Can you spell out the sort of tables of data that report() will take, what other options it will have and so on, and what its output will be. It is quite possible someone out there will go "Yeah, I can do that", and have a go, especially if they also go "Yeah, I could *use* that too". If you really want it done, then you can pay money. So, spec please. From your earlier postings it sounds like not much more than summary(d) and a few table(d) outputs. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
On Sun, Aug 22, 2010 at 4:33 PM, ivo welch wrote:
> Dear R development Team: I really know very little, so you may ignore
> this post. I have found that my students often make the mistake of
> mixing up comparisons and assignments with negative numbers:
>
> if (x<-3) do_something;
>
> I parenthesize, but every once in a while, I forget and commit this
> mistake, too. so, I would suggest that R simply warn about an
> ambiguity. that is, it could suggest a space either between the < and
> - , or after the <- .
>
> x< -3 ## means comparison already
> x<- 3 ## means assignment already
> but warn when
> x<-3 ## ambiguity warning instead of assignment
> x<-(whatever) ## ok
>
> just a suggestion...
>
If you tell your students not to use '<-' for assignment, then they
can't make this mistake, because = for assignment has additional
restrictions on it:
> x
[1] 3
> if(x=3)print("yay")
Error: unexpected '=' in "if(x="
Anyway, if students didn't make mistakes how will they learn about debugging?
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
On Mon, Aug 23, 2010 at 6:06 PM, Davor Cubranic wrote:
> The students are trying to *compare* to a negative number, and trip on R's
> parsing of "<-". They could use '=' for assignment all they want (which I
> thought is being discouraged as a code style these days, BTW), and they'll
> still run into this problem.
Oops yes, negative logic assumption from me.
Okay, back to the question...
Looks tricky, because if(x=2){...} fails because of syntax. There's
stuff in gram.y that makes x=1 a bit special, and only lets it occur
as a top-level expression. However x<-1 is allowed anywhere an
expression can be. Both expressions then call the same 'primitive'
function. At that point I'm not sure how the code could find out if
it's being called from a <- or an = assignment. And then whether its a
top-level expression or not. And this would need checking on every <-
call, which could be a problem...
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
On Tue, Aug 24, 2010 at 4:18 PM, Ted Harding wrote: > So, on those grounds, I doubt its wisdom (and would prefer > giving the advice to bracket things, as in "x<(-3)". It's > a potential syntactic trap, but it's only one of many which > can be avoided in similar ways, and I think it's better to > teach avoidance rather than warning after the event. Actually I think its better to teach _testing_ since it is hard to teach all the things to avoid - they're not all listed in Patrick Burns' R Inferno! (This particular problem *is* listed on page 49 of said marvellous tome). Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
On Tue, Aug 24, 2010 at 3:28 PM, Michael Dewey wrote: > The thing I find most rude on the list is not the occasional abrupt postings > by people who are obviously having a bad day but the number of fairly long > exchanges which end unresolved as the OP never bothers to post a conclusion > and we never know whether we solved his/her problem. > I am not asking for thanks but we would all benefit from knowing how it all > turned out. The elephant in the room is, I think, the idea that maybe mailing lists have had their day - if R-help was a web-based forum then threads could be moderated by a group of privileged individuals, or rated by users. Basically, stackoverflow.com For anyone who has never visited: http://stackoverflow.com/questions/tagged/r Good answers get modded up, bad ones slide off. I'm considering unsubbing from r-help, and adding the R feed from stackoverflow to my RSS reader... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] An ls error which is not an error...
If I try ls with an unquoted version of something in my search list, I
get an error message but the ls completes successfully. For example:
> attach("x.RData")
> ls(file:x.RData)
Error in try(name) : object 'x.RData' not found
[1] "x"
which seems to be because ls first does: nameValue <- try(name) which
raises the error, and then goes on to do some
substitute(deparse(magic)) to get the name and carries on as if I'd
done ls("file:x.RData")
Documentation says (with my enumeration):
The ‘name’ argument can specify the environment from which object
names are taken in one of several forms:
1. as an integer (the position in the ‘search’ list);
2. as the character string name of an element in the search list;
3. or as an explicit ‘environment’
Either ls(file:x.RData) is none of these in which case there should be
an error and exit, or it's (2), in which case the error is misleading.
I think try(name,silent=TRUE) might be a better option?
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non identical numerical results from R code vs C/C++ code?
On Fri, Sep 10, 2010 at 11:46 AM, Renaud Gaujoux wrote: > Hi, > > suppose you have two versions of the same algorithm: one in pure R, the > other one in C/C++ called via .Call(). > Assuming there is no bug in the implementations (i.e. they both do the same > thing), is there any well known reason why the C/C++ implementation could > return numerical results non identical to the one obtained from the pure R > code? (e.g. could it be rounding errors? please explain.) > Has anybody had a similar experience? > > By not identical, I mean very small differences (< 2.4 e-14), but enough to > have identical() returning FALSE. Maybe I should not bother, but I want to > be sure where the differences come from, at least by mere curiosity. > > Briefly the R code perform multiple matrix product; the C code is an > optimization of those specific products via custom for loops, where entries > are not computed in the same order, etc... which improves both memory usage > and speed. The result is theoretically the same. I've had almost exactly this situation recently with an algorithm I first implemented in R and then in C. Guess what the problem was? Yes, a bug in the C code. At first I thought everything was okay because the returned values were close-ish, and I thought 'oh, rounding error', but I wasn't happy about that. So I dug a bit deeper. This is worth doing even if you are sure there no bugs in the C code (remember: there's always one more bug). First, construct a minimal dataset so you can demonstrate the problem with a manageable size of matrix. I went down to 7 data points. Then get the C to print out its inputs. Identical, and as expected? Good. Now debug intermediate calculations, printing or saving from C and checking they are the same as the intermediate calculations from R. If possible, try returning intermediate calculations in C and checking identical() with R intermediates. Eventually you will find out where the first diverge - and this is the important bit. It's no use just knowing the final answers come out different, it's likely your answer has a sensitive dependence on initial conditions. You need to track down when the first bits are different. Or it could be rounding error... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Check for updates under Windows (Was: a reliable way to check the latest version of R on CRAN?)
On Sat, Sep 18, 2010 at 11:17 PM, Yihui Xie wrote:
> Dear R developers,
>
> I asked this question in r-help list but have not got a definite
> solution yet, and I think it might be more appropriate to ask
> developers or CRAN maintainers directly. Many software packages often
> have a menu item like "Check for updates" under the "Help" menu, e.g.
> Filezilla and Firefox, and I believe it is also necessary for R (at
> least for R GUI under Windows). Note all users really have to update
> R, but we should make it clearer to them that new versions are
> available. Yes, they can go to R homepage to check by themselves, but
> my experience tells me it is rarely the case. Therefore, I wish RGui
> could gain a new menu to check for updates of R. Thanks very much!
Something like this:
winMenuAdd("Updates"); winMenuAddItem("Updates","R
Version","require(gtools);checkRVersion()")
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stats, pics etc on CRAN
Does anyone have some nice ways of showing what's on CRAN? A time-series of the number of packages? A clustered graph of packages by keyword? I'm just after a more impressive way of saying "there's 2600 packages on CRAN" than saying that. Counts of lines of R and C/Fortran code would be interesting... The CRANtastic tag cloud is quite handy... Anything else? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R vs. C
On Mon, Jan 17, 2011 at 6:57 PM, David Henderson wrote: > I think we're also forgetting something, namely testing. If you write your > routine in C, you have placed additional burden upon yourself to test your C > code through unit tests, etc. If you write your code in R, you still need the > unit tests, but you can rely on the well tested nature of R to allow you to > reduce the number of tests of your algorithm. I routinely tell people at Sage > Bionetworks where I am working now that your new C code needs to experience at > least one order of magnitude increase in performance to warrant the effort of > moving from R to C. > > But, then again, I am working with scientists who are not primarily, or even > secondarily, coders... If you write your code in C but interface to it in R, you can use the same R test harness system. I recently coded something up in R, tested it on small data, discovered it was waaay too slow on the real data, rewrote the likelihood calculation in C, and then used the same test set to make sure it was giving the same answers as the R code. It wasn't. So I fixed that bug until it was. If I'd written the thing in C to start with I might not have spotted it. Sometimes writing a prototype in R is a useful testing tool even when you know it'll be too slow - as an interpreted language R gives you a rapid development cycle and handy interactive debugging possibilities. Things that do exist in C but require compilation Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Easily switchable factor levels
I've recently been working with some California county-level data. The
counties can be referred to as either FIPS codes, eg F060102, friendly
names such as "Del Norte County", names without 'County' on the end,
names with 'CA' on the end ("Del Norte County, CA"). Different data
sets use slightly different forms and putting them all together is a
pain.
So I was wondering about ways to attach multiple sets of level codes
to a factor. It would work something like this:
> foo=multifactor(sample(letters,5),levels=letters,levelname="lower")
> foo
[1] m u i z b
Levels: a b c d ... y z
> levels(foo,"upper") = LETTERS
> uselevels(foo,"upper")
> foo
[1] M U I Z B
Levels: A B C D E FZ
> uselevels(foo,"lower")
> foo
[1] m u i z b
Levels: a b c d z
In this way you could easily switch your levels from M and F to Male
and Female, or Hommes et Dames, without having to do levels(foo) =
something and hope to get the ordering right every time. Just do it
once, keep the multiple sets of level lables in the object.
I'd even throw in a function to print out all the level codes:
> levels(foo,all=TRUE)
upper lower
[1] A a
[2] B b
etc
I can see assorted problems coding this up to cope with dropping
levels when making subsets... and possibly problems when code does
character matching of levels and expects them to be unchanged...
Has anyone bothered to write anything like this yet? Or is the
application a bit too rare to be worth it?
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to disable R's crash prompt
On Tue, Mar 8, 2011 at 2:24 PM, wrote: > Dear R devel, > > I have a C++ app that calls into embedded R to perform some analytic > calculations. When my app encounters a segmentation fault, R always prints > the following crash prompt and asks me to enter an action: > > > *** caught segfault *** > address 0x8, cause 'memory not mapped' > > Possible actions: > 1: abort (with core dump, if enabled) > 2: normal R exit > 3: exit R without saving workspace > 4: exit R saving workspace > > > > The problem is my app will be run in non-interactive mode, so there is no way > for me to enter the action. Is there a way to disable the crash prompt and > have R simply crash the whole app? I have tried using "-file=/dev/null", > "-slave", "-vanilla", and pretty much all other start options, to no avail. If someone from Barclays Capital is writing programs that are being allowed to seg fault and they want to *ignore* the seg fault then I'm taking all my money away from Barclays Capital and keeping it away. Barclays Capital, the bank that likes to say "seg fault". Your code can't possibly seg fault - our governments are always telling us banks are too big to fail. That's enough banker bashing. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to disable R's crash prompt
On Tue, Mar 8, 2011 at 10:41 PM, wrote: > That did the trick. Thank you soo much Simon! But really you *should* fix the segfault. Either you know why it happens, in which case you should spot it before it happens and do something sensible, or you don't know why it happens, in which case it could be a serious bug in your code. Even if you *do* know why it happens, there may be other bugs in your code that cause segfaults that you *dont* know about, and you'll miss them because you are stupidly ignoring all segfaults. Fix the bugs. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish there were a "strict mode" for R interpreter. What
On Sat, Apr 9, 2011 at 10:08 PM, Ted Harding wrote: > I'm with Duncan on this one! On the other hand, I can understand the > issues that Paul's students might encounter. > > I think the right thing to so is to introduce the students to the > basics of scoping, early in the process of learning R. Would that be before or after you introduce them to the basics of testing? Hint: AFTER! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Recursive objects
On Wed, May 4, 2011 at 2:21 PM, Hadley Wickham wrote: > Any hints as to what to search for? For recursive objects, search for recursive objects. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fortan common block
On Fri, May 6, 2011 at 4:04 PM, Paul Gilbert
wrote:
> Is it possible in R to call a fortran routine that sets variables in a common
> block and expect the values to persist when a call is made from R to a second
> routine that uses the common block?
>
> If not (as I suspect), is it possible to use a common block in a group of
> routines that are used together, for as long the routines do not return to R?
Simple test seems to confirm it. Here's some 'tran with a setter and a getter:
comchk.f:
subroutine bar(n)
common /c/ i
i=n
end
subroutine geti(j)
common /c/ i
j = i
end
R CMD SHLIB comchk.f
> dyn.load("comchk.so")
> .Fortran("bar",as.integer(9))
[[1]]
[1] 9
> .Fortran("geti",as.integer(-1))
[[1]]
[1] 9
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] non-R package development
On Sat, May 21, 2011 at 2:04 AM, Spencer Graves wrote: > I routinely use the "R CMD check", etc., process with Subversion for > version control and collaborative development. I've looked for similar > capabilities for other languages, so far without success. Python has a similar package build system based around a directory structure with a 'setup.py' at its root - you may have seen this if youve ever installed a python package from source. This python script enables you to do things like 'python setup.py build' and 'python setup.py install' to build and install the package, as well as run tests, build distributable archives and so on. There's probably a way to get a boilerplate package structure all ready to start developing but I cant think what it is off the top of my head. SVN and most other version control systems will play nicely with text-based program development, so get checking in your python, matlab, and unix scripts. If LabVIEW has a binary format then you can normally check these in but you won't get meaningful 'diffs' out of the system to see what has changed between revisions. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Please explain your workflow from R code -> package -> R code -> package
On Fri, Sep 9, 2011 at 7:41 PM, Hadley Wickham wrote: > It's not the cool kids who are doing this, it's the lazy kids ;) laziness being one of the three virtues of a programmer. The other two being hubris and something else I don't have time to look up at the moment. library(fortunes) fodder: "Don't do as I say, do as Hadley does." -- blog: http://geospaced.blogspot.com/ web: http://www.maths.lancs.ac.uk/~rowlings web: http://www.rowlingson.com/ twitter: http://twitter.com/geospacedman pics: http://www.flickr.com/photos/spacedman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Link between Qt GUI and R
On Sun, Sep 11, 2011 at 11:30 AM, typhoong wrote: > hi, > > i want to build a Qt front-end GUI which communicates with R, and i am not > sure what i should use for the interface. There seems to be many ways: > R.dll, Rinside, Rcpp, RQt, Rtools... . what is the best way? please advice. > Another way is to write the Qt GUI code in Python using the PyQt4 classes, then use RPy to call the required R functionality, get the results back, slap them into the GUI. If you can program in Python or want to learn it then its the best way by far :) Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Link between Qt GUI and R
On Mon, Sep 12, 2011 at 2:00 AM, typhoong wrote: > hi everyone, thanks for all the tips. > > > Barry, can you tell me why you think PyQT is by far the best way? I said that conditional on you knowing or wanting to learn Python. Python interacts with Qt in much the same way as C++ interacts with it, but without the annoying compile and link steps of C++ (Python is an interpreted language). Qt was designed to work with C++, and so development with Python and C++ should be faster than most other Qt interfaces. So if you already know Python, and your R scripts are already in the can ready to go, there's less point learning, or even constructing, some R-Qt interface than using the well-established and robust Python-Qt interface. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multi-line comments in R
On Wed, Aug 19, 2015 at 5:16 AM, Nathan Esau wrote:
> I was wondering why the decision was made long ago to never implement
> multi-line comments in R. I feel there are several argument to be made for
> why the R language should have multi-line comments.
>
> 1. Many programming languages (including some which are commonly used for
> statistics, such as python, matlab and SAS) have this feature.
Python doesn't have a multi-line comment.
You can use triple-quoted strings in Python to quote a large chunk of
text, which won't generate any bytecode and so has no executable
effect:
def foo(x)
y = x * 2
"""
well what now
lets have a comment
"""
return(y)
A similar thing is possible in R:
foo = function(x){
"this is a test.
where
you can comment"
return(x*2)
}
However I don't know if this causes any executable effect - its
possible R evaluates the string in some way Anyone want to test.
Yes, you have to escape any string quote marks in your comment, but in
python you have to escape any triple-quote marks.
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Source code of early S versions
According to Wikipedia: "In 1980 the first version of S was distributed outside Bell Laboratories and in 1981 source versions were made available." but I've been unable to locate any version of S online. Does anyone have a copy, somewhere, rusting away on an old hard disk or slowly flaking off a tape? I've had a rummage round the CMU Statlib on archive.org but no sign of it, and its hard to search for "S" generally. Obviously this would be for archaeological purposes, but there's bound to be someone out there who'd like to try and compile it on a modern system. It might at least be nice to see it in a nice format on Gitlab, for example. But maybe there's licensing problems. Anyone interested in the history of S should read Richard Becker's article from the mid 90s: http://sas.uwaterloo.ca/~rwoldfor/software/R-code/historyOfS.pdf Barry [apologies if S talk is off-topic. Surprisingly I've just discovered the S-news mailing list still runs, but looking at the recent archive I don't think I'd get much success there] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Source code of early S versions
On Mon, Feb 29, 2016 at 6:17 PM, John Chambers wrote: > The Wikipedia statement may be a bit misleading. > > S was never open source. Source versions would only have been available with > a nondisclosure agreement, and relatively few copies would have been > distributed in source. There was a small but valuable "beta test" network, > mainly university statistics departments. So it was free (or at least distribution cost only), but with a nondisclosure agreement? Did binaries circulate freely, legally or otherwise? Okay, guess I'll read the book. I'm sure I saw S source early in my career (1990 or so), possibly on an early Sun 3/60 system or even the on-the-way-out Whitechapel MG-1 workstations. > And two shameless plugs: > > 1. there is a chapter on the history of all this in my forthcoming book on > "Extending R" That will sit nicely on the shelf next to "Extending The S System" that Allan Wilks gave me :) > PS: somehow "historical" would be less unnerving than "archeological" At least I didn't say palaeontological. Thanks for the response. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A trap for young players with the lapply() function.
On Mon, Mar 27, 2017 at 1:17 AM, Rolf Turner wrote:
>
> Is there any way to trap/detect the use of an optional argument called
> "X" and thereby issue a more perspicuous error message?
>
> This would be helpful to those users who, like myself, are bears of very
> little brain.
>
> Failing that (it does look impossible)
You can get the names of named arguments:
> z = function(x,X){cos(x*X)}
> names(formals(z))
[1] "x" "X"
> might it not be a good idea to
> add a warning to the help for lapply(), to the effect that if FUN has an
> optional argument named "X" then passing this argument via "..." will
> cause this argument to be taken as the first argument to lapply() and
> thereby induce an error?
Another idea might be to use purrr:map instead, which is quite happy
with X in your function:
> xxx <- purrr::map(y,function(x,X){cos(x*X)},X=2*pi)
> xxx
[[1]]
[1] 0.08419541
[[2]]
[1] 0.6346404
[[3]]
[1] 0.9800506
[[4]]
[1] 0.8686734
[[5]]
[1] -0.9220073
But don't feed `.x` to your puing cats, or fails silently:
> xxx <- purrr::map(y,function(x,.x){cos(x*.x)},.x=2*pi)
> xxx
[[1]]
NULL
But who would have a function with `.x` as an argument?
> __
> 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] R on OpenHub
Does anyone want to manage the record for R on OpenHub? OpenHub is a site that records metrics for open source projects. At some point a record for R was created: https://www.openhub.net/p/r_project but there's no manager listed. OpenHub says: """ * Only someone who works on the project and has a close connection to it should apply. Ideally the owner, founder, lead developer, or release manager. """ So not me. Sounds more like it needs to be someone in R-core or an R Foundation luminary. OpenHub is used by the OSGeo Live DVD to generate metrics for all the projects on the DVD, and I've just been asked by the OSGeo Live team to inquire about this. If nobody wants to do it, no biggie, I think it just means the project information will be less accurate. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] attach "warning" is a message
If I mask something via `attach`: > d = data.frame(x=1:10) > x=1 > attach(d) The following object is masked _by_ .GlobalEnv: x > I get that message. The documentation for `attach` uses the phrase "warnings", although the message isn't coming from `warning()`: warn.conflicts: logical. If ‘TRUE’, warnings are printed about ‘conflicts’ from attaching the database, unless that database contains an object ‘.conflicts.OK’. A conflict is a function masking a function, or a non-function masking a non-function. and so you can't trap them with options(warn=...) and so on. This sent me briefly down the wrong track while trying to figure out why R was showing a masking error in one context but not another - I wondered if I'd supressed warning()s in the other context. Personally I'd like these messages to be coming from warning() since that seems the appropriate way to warn someone they've done something which might have unwanted effects. But fixing the documentation to say "If ‘TRUE’, *messages* are printed" is probably less likely to break existing code. Happy to add something to bugzilla if anyone thinks I'm not being overly pedantic here. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] subfolders in the R folder
The "good reason" is all the tooling in R doesn't work with subfolders and would have to be rewritten. All the package check and build stuff. And that's assuming you don't want to change the basic flat package structure - for example to allow something like `library(foo)` to attach a package and `library(foo.bar)` to attach some subset of package `foo`. That would require more changes of core R package and namespace code. As a workaround, you could implement a hierarchical structure in your file *names*. That's what `ggplot2` does with its (...downloads tarball...) 192 files in its R folder. Well mostly, there's a load of files called annotation- and geom- and plot- and position- and stat- etc etc. No reason why you can't have multiple "levels" separated with "-" as you would have multiple folder levels separated with "/". You can then do `ls geom-*` to see the `geom` "folder" and so on (on a unix shell). And then when R Core receive a patch that implements subfolders, a quick shell script will be able to create the hierarchy for you and drop all the files in the right place. One reason for the flat folder structure may be that R's packages themselves have no structure to the functions - compare with Python where modules can have subfolders and functions in subfolders can be access with module.subfolder.subsub.foo(x), and module subfolders can be imported etc. The whole module ecosystem was designed with structure in mind. I don't think there's any restriction on subfolders in the "inst" folder of a package so if you have scripts you can arrange them there. Given that most of my students seem to keep all their 23,420 files in one folder called "Stuff" I think we can manage like this for a bit longer. B On Tue, Mar 28, 2023 at 4:43 PM Antoine Fabri wrote: > This email originated outside the University. Check before clicking links > or attachments. > > Dear R-devel, > > Packages don't allow for subfolders in R with a couple exceptions. We find > in "Writing R extensions" : > > > The R and man subdirectories may contain OS-specific subdirectories named > unix or windows. > > This is something I've seen discussed outside of the mailing list numerous > times, and thanks to this SO question > > https://stackoverflow.com/questions/14902199/using-source-subdirectories-within-r-packages-with-roxygen2 > I could find a couple instances where this was discussed here as well, > apologies if I missed later discussions : > > * https://stat.ethz.ch/pipermail/r-devel/2009-December/056022.html > * https://stat.ethz.ch/pipermail/r-devel/2010-February/056513.html > > I don't see a very compelling conclusion, nor a justification for the > behavior, and I see that it makes some users snarky (second link is an > example), so let me make a case. > > This limitation is an annoyance for bigger projects where we must choose > between having fewer files with too many objects defined (less structure, > more scrolling), or to have too many scripts, often with long prefixed > names to emulate essentially what folders would do. In my experience this > creates confusion, slows down the workflow, makes onboarding or open source > contributions on a new project harder (where do we start ?), makes dead > code easier to happen, makes it harder to test the rights things etc... > > It would seem to me, but I might be naive, that it'd be a quick enough fix > to flatten the R folders not named "unix" or "windows" when building the > package. Is there a good reason why we can't do that ? > > Thanks, > > Antoine > > PS: > Other SO Q&As: > https://stackoverflow.com/questions/33776643/subdirectory-in-r-package > > https://stackoverflow.com/questions/18584807/code-organisation-in-r-package-development > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: zapsmall(x) for scalar x
I think what's been missed is that zapsmall works relative to the absolute
largest value in the vector. Hence if there's only one
item in the vector, it is the largest, so its not zapped. The function's
raison d'etre isn't to replace absolutely small values,
but small values relative to the largest. Hence a vector of similar tiny
values doesn't get zapped.
Maybe the line in the docs:
" (compared with the maximal absolute value)"
needs to read:
" (compared with the maximal absolute value in the vector)"
Barry
On Sun, Dec 17, 2023 at 2:17 PM Duncan Murdoch
wrote:
> This email originated outside the University. Check before clicking links
> or attachments.
>
> I'm really confused. Steve's example wasn't a scalar x, it was a
> vector. Your zapsmall() proposal wouldn't zap it to zero, and I don't
> see why summary() would if it was using your proposal.
>
> Duncan Murdoch
>
> On 17/12/2023 8:43 a.m., Gregory R. Warnes wrote:
> > Isn’t that the correct outcome? The user can change the number of
> digits if they want to see small values…
> >
> >
> > --
> > Change your thoughts and you change the world.
> > --Dr. Norman Vincent Peale
> >
> >> On Dec 17, 2023, at 12:11 AM, Steve Martin
> wrote:
> >>
> >> Zapping a vector of small numbers to zero would cause problems when
> >> printing the results of summary(). For example, if
> >> zapsmall(c(2.220446e-16, ..., 2.220446e-16)) == c(0, ..., 0) then
> >> print(summary(2.220446e-16), digits = 7) would print
> >>Min. 1st Qu. MedianMean 3rd Qu.Max.
> >> 0 00 0 0 0
> >>
> >> The same problem can also appear when printing the results of
> >> summary.glm() with show.residuals = TRUE if there's little dispersion
> >> in the residuals.
> >>
> >> Steve
> >>
> >>> On Sat, 16 Dec 2023 at 17:34, Gregory Warnes wrote:
> >>>
> >>> I was quite suprised to discover that applying `zapsmall` to a scalar
> value has no apparent effect. For example:
> >>>
> y <- 2.220446e-16
> zapsmall(y,)
> >>> [1] 2.2204e-16
> >>>
> >>> I was expecting zapsmall(x)` to act like
> >>>
> round(y, digits=getOption('digits'))
> >>> [1] 0
> >>>
> >>> Looking at the current source code, indicates that `zapsmall` is
> expecting a vector:
> >>>
> >>> zapsmall <-
> >>> function (x, digits = getOption("digits"))
> >>> {
> >>> if (length(digits) == 0L)
> >>> stop("invalid 'digits'")
> >>> if (all(ina <- is.na(x)))
> >>> return(x)
> >>> mx <- max(abs(x[!ina]))
> >>> round(x, digits = if (mx > 0) max(0L, digits -
> as.numeric(log10(mx))) else digits)
> >>> }
> >>>
> >>> If `x` is a non-zero scalar, zapsmall will never perform rounding.
> >>>
> >>> The man page simply states:
> >>> zapsmall determines a digits argument dr for calling round(x, digits =
> dr) such that values close to zero (compared with the maximal absolute
> value) are ‘zapped’, i.e., replaced by 0.
> >>>
> >>> and doesn’t provide any details about how ‘close to zero’ is defined.
> >>>
> >>> Perhaps handling the special when `x` is a scalar (or only contains a
> single non-NA value) would make sense:
> >>>
> >>> zapsmall <-
> >>> function (x, digits = getOption("digits"))
> >>> {
> >>> if (length(digits) == 0L)
> >>> stop("invalid 'digits'")
> >>> if (all(ina <- is.na(x)))
> >>> return(x)
> >>> mx <- max(abs(x[!ina]))
> >>> round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L,
> digits - as.numeric(log10(mx))) else digits)
> >>> }
> >>>
> >>> Yielding:
> >>>
> y <- 2.220446e-16
> zapsmall(y)
> >>> [1] 0
> >>>
> >>> Another edge case would be when all of the non-na values are the same:
> >>>
> y <- 2.220446e-16
> zapsmall(c(y,y))
> >>> [1] 2.220446e-16 2.220446e-16
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>> Gregory R. Warnes, Ph.D.
> >>> g...@warnes.net
> >>> Eternity is a long time, take a friend!
> >>>
> >>>
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > 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
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: capture "->"
It seems like you want to use -> and <- as arrows with different meanings
to "A gets the value of B" in your package, as a means of writing
expressions in your package language.
Another possibility would be to use different symbols instead of the
problematic -> and <-, for example you could use <.~ and ~.> which are not
at all flipped or changed before you get a chance to parse your expression.
It might make your language parser a bit trickier though. Let's see how
these things turn into R's AST using `lobstr`:
> library(lobstr)
> ast(A ~.> B)
█─`~`
├─A
└─█─`>`
├─.
└─B
> ast(A <.~ B)
█─`~`
├─█─`<`
│ ├─A
│ └─.
└─B
You'd have to unpick that tree to figure out you've got A and B on either
side of your expression, and that the direction of the expression is L-R or
R-L.
You could also use -.> and <.- symbols, leading to a different tree
> ast(A -.> B)
█─`>`
├─█─`-`
│ ├─A
│ └─.
└─B
> ast(A <.- B)
█─`<`
├─A
└─█─`-`
├─.
└─B
Without knowing the complexity of your language expressions (especially if
it allows dots and minus signs with special meanings) I'm not sure if A)
this will work or B) this will bend your brain in horrible directions in
order to make it work... Although you don't need to parse the AST as above,
you can always deparse to get the text version of it:
> textex = function(x){deparse(substitute(x))}
> textex(A <.~ B)
[1] "A < . ~ B"
The <.~ form has an advantage over the <.- form if you want to do complex
expressions with more than one arrow, since the ~ form is syntactically
correct but the - form isnt:
> textex(A <.~ B ~.> C)
[1] "A < . ~ B ~ . > C"
> textex(A <.- B -.> C)
Error: unexpected '>' in "textex(A <.- B -.>"
Barry
On Sun, Mar 3, 2024 at 12:25 PM Dmitri Popavenko
wrote:
> This email originated outside the University. Check before clicking links
> or attachments.
>
> On Sat, Mar 2, 2024 at 7:58 PM Gabor Grothendieck >
> wrote:
>
> > Would it be good enough to pass it as a formula? Using your definition
> of
> > foo
> >
> > foo(~ A -> result)
> > ## result <- ~A
> >
> > foo(~ result <- A)
> > ## ~result <- A
> >
>
> Yes, to pass as a formula would be the idea.
> It's just that the parser inverses "~A -> result" into "result <- ~A".
> We are seeking for any way possible to flag this inversion.
>
> Avi, thank you for your efforts too. Wrapping symbols into percent signs is
> an option, but as Duncan says it is much more intuitive to just quote the
> expression.
> The challenge is to somehow flag the parser inversion, otherwise a quoted
> expression seems to be the only solution possible.
>
> Regards,
> Dmitri
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R6 "classname" and generator name
I'm writing some code that does a bit of introspection of R6 classes and am
wondering about the "classname" parameter. Its the first parameter to the
"R6Class" class generator generator function, and the few examples I've
looked at on CRAN set it the same as the name of the generator function,
for example, from the docs:
Queue <- R6Class("Queue", .)
but this isn't mandatory, it can be anything. Or NULL. (side quest: do
linters exist that flag this as bad style?).
Does anyone have an example of a CRAN package where this isn't the case? Or
even where an R6 class generator uses the default "NULL" for its classname
parameter? My introspection code is in two minds whether to use the
classname to label diagrams of classes, or to use the names of the actual
generator functions (which are what the package users should be using), or
show both if different, or flag up NULL values etc...
Never should have opened this can of worms. I don't even like worms.
Barry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: R for the US Air Force
R is not a product that is provided by a company or any vendor that can be > procured through a vendor e.g. something on a GSA schedule. > > that's not strictly true though is it? Anyone can form a company and supply R, as long as everyone complies with the license. You are also free to download R from public services and do it without any corporate wrappings and trappings, which is what Posit (ex-RStudio) do, right? > Seems like you're caught in the bureaucracy hell hole. I used to help the > USAF, and other DoD members use R when I was at RStudio (now Posit). > I don't see anything in the PDF posted that links the software to the company details required. Does it have to be the copyright holder of the software? Or anyone free to distribute it by license? Does the USAF use other open source systems, eg Linux, in which case are they going through a licensed reseller to tick these boxes? Barry > > On Thu, May 16, 2024 at 2:57 PM ADAMS, DOUGLAS L CIV USAF AFMC OO-ALC/OBWA > via R-devel wrote: > > > Hello, > > > > > > > > The US Air Force used to have R available on our main network, but now > > those who need to accept it back are > > being very particular about what they're accepting in terms of official > > documentation. > > > > > > > > Would you be able to help me with this endeavor? I'm attaching a pdf > that > > shows what documentation they'd > > require for us to re-establish R as being acceptable on the network here. > > I understand if you're too busy or > > if it's a pain. Haha > > > > > > > > Thank you so much for your help and consideration! > > > > > > > > Doug Adams > > > > United States Air Force > > > > Hill AFB, Utah > > > > > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: R for the US Air Force
> that's not strictly true though is it? Anyone can form a company and > supply R, as long as everyone complies with the license. You are also free > to download R from public services and do it without any corporate > wrappings and trappings, which is what Posit (ex-RStudio) do, right? > > [correction for clarity: I mean Posit *do* supply R with corporate "wrappings and trappings" (whatever they are), the logic may have got twisted there in edits] B [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Re: Segfault when parsing UTF-8 text with srcrefs
I get an R error and no segfault:
> parse(textConnection(text), srcfile = srcfile)
Error in parse(textConnection(text), srcfile = srcfile) :
test.r:1:1: unexpected $end
1: ×
^
This is R 4.3.0, so maybe the bug has been introduced since then...
Version and system info:
> version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 4
minor 3.0
year 2023
month 04
day21
svn rev84292
language R
version.string R version 4.3.0 (2023-04-21)
nickname Already Tomorrow
> sessionInfo()
R version 4.3.0 (2023-04-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 22.04.4 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so;
LAPACK version 3.10.0
locale:
[1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
time zone: Europe/London
tzcode source: system (glibc)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.3.0
On Tue, May 28, 2024 at 7:42 PM Tomas Kalibera
wrote:
> This email originated outside the University. Check before clicking links
> or attachments.
>
> On 5/28/24 19:35, Hadley Wickham wrote:
> > Hi all,
> >
> > When I run the following code, R segfaults:
> >
> > text <- "×"
> > srcfile <- srcfilecopy("test.r", text)
> > parse(textConnection(text), srcfile = srcfile)
> >
> > It doesn't segfault if text is ASCII, or it's not wrapped in
> > textConnection, or srcfile isn't set.
>
> Thanks, this is because R parser doesn't support non-ASCII UTF-8 outside
> string literals and comments, plus a missing bounds check. The "correct"
> result should be an R error, which I get in a debug build.
>
> The tokenizer ends up with a negative token and then when the parse data
> are being finalized, creating a table of token names, there is an out of
> bounds access (yytname array). Probably the check should go right away
> into the tokenizer.
>
> Tomas
>
> >
> > Hadley
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should the text for RIGHT_ASSIGN be -> in getParseData()?
On Fri, Jul 5, 2013 at 12:57 PM, Duncan Murdoch wrote: > R itself doesn't make use of the text column, it's for display of code > by highlighters etc. So if anyone does assume text is a function name, > it's their bug, not ours. In fact, the bug is already there, because > there is actually one other example which was being parsed properly, > "**" is translated to "^". There's no `**` function, but 2**3 works. Is there any reason right-assign with "->" still exists? How much code on CRAN uses it, and how trivially could it be excised? Can we also have 'up assign' and "down assign" so I can do: > 3 > x -^ > x -v > 4 - they make just as much sense. Okay, lets see all the edge cases. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should the text for RIGHT_ASSIGN be -> in getParseData()?
On Fri, Jul 5, 2013 at 7:24 PM, peter dalgaard wrote:
> I have used in with multi-line input, occasionally, though. As in
>
> replicate(1, {
>ysim <- rbinom(length(p), n, p)
>glm(cbind(ysim, n - ysim) ~ x, binomial)$deviance
> })
>
> ... and then you realize that you probably don't want to look at 1
> simulated deviances and add "-> simDev".
>
Yes, that's kinda cute, but then you realise you don't want to have
to type all that again and it would really be better off in a
function. Can you do something like:
replicate(1,{
ysim <- rbinom(length(p), n, p)
glm(cbind(ysim, n - ysim) ~ x, binomial)$deviance
}) -> function()...
- I don't think so. Once you've started typing, the only way to get
it into a function is going to involve sticking function() at the
start, at which point you can add the foo <-
I guess this is the point where Dirk gets upset and calls me a troll.
I'll shut up. You've convinced me its mostly harmless.
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with distributing data in package.
On Fri, Jul 19, 2013 at 10:33 AM, Simon Knapp wrote: > Hi List, > > I am building a package for a client to help them create and perform > analyses against netcdf files which contain 'a temporal stack' of > grids. > > For my examples and test cases, I create an example dataset in code > (as this is a lot more space efficient than providing raw data). The > code creates a netcdf file in tempdir() and an object of class 'ncdf' > in the global namespace. I have placed the code in a .R file in the > data directory of my package and 'load' it with a call to data(). Why not just put the function that generates the data file into the usual place (/R/ folder) and document it so that the user knows to run 'sampledata=makeSampleNCDF()' before doing things that need it? Trying to put executable code into the data folder does seem a bit perverse! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Internalization of help pages
[I've tried to move this back to R-devel, which I think is what Brian
Ripley tried and nobody followed...]
On Sun, Aug 4, 2013 at 4:15 PM, John Kane wrote:
> I tried it in French and there a few hiccups but it's not too bad.
>
> Personally I'd like to see the help tranlated into English too.l
>
> John Kane
> Kingston ON Canada
The problems of getting translations for help pages are many-fold:
1. Giving translators access to current .Rd files, which is tricky
when people are developing with roxygen2.
2. Finding translators to do the work. There are a lot of tools for
helping translate message files, but whole .Rd docs might be too much
for the casual translator.
3. Having a standard way to display help in language X if it exists,
considering the complexity of R's help (plain text, web, PDF
versions). Put it all in help/XX and html/XX and doc/XX for XX in
languages?
4. As (3) but with vignettes. Wouldn't vignette("foo",language="fr")
be nice if "foo" was available in French? Or vignette(language="de")
to get all German vignettes?
5. Language bloat. Best solved by making language documentation 'add
on' packs. Easier for a package developer to do for one package, hard
for core R with several packages and core documentation.
6. How do you integrate that with CRAN?
7. Does CRAN have to build all the built languages documentation from
the language .Rd files? A standard repository structure on github and
some github_ wrapper functions might help kick this off since there
wouldn't be a need to bother the busy CRAN people with things.
Of all of that I reckon foreign-language vignette support might be the
easiest to implement. It would seem to require a way for an author to
specify the language of a vignette, a standard place for languaged
vignettes (source and built), and a mod to the vignette function to
look in those places.
The comparable translation project I know of is the translation of
documents for the OSGeo Live DVD - this consists of translations of
short project introductions and walkthroughs (with screenshots) for
about 50 pieces of software, which is probably of the order of
difficulty of translating an R package with about 100 well-documented
functions. It works well but it does have a lot of commitment from
everyone every six months at the release points.
However, getting all the R documentation translated is probably easier
than getting everyone to speak english - we started trying to do that
in the 18th century and look how that turned out...
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposal for new FAQ entry?
On Mon, Aug 5, 2013 at 2:53 PM, peter dalgaard wrote: >> Does this seem FAQ-worthy? Should I e-mail the FAQ maintainer and suggest >> it? > > Sure, as long as we never change the numbering of FAQ 7.31... > Not even to FAQ 7.31+1e-15 ? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Multiple return values / bug in rpart?
On Mon, Aug 12, 2013 at 6:06 PM, Justin Talbot wrote:
> In the recommended package rpart (version 4.1-1), the file rpartpl.R
> contains the following line:
>
> return(x = x[!erase], y = y[!erase])
>
> AFAIK, returning multiple values like this is not valid R. Is that
> correct? I can't seem to make it work in my own code.
Works for me, returning a list:
> foo
function(x){return(x,x*2)}
> foo(99)
[[1]]
[1] 99
[[2]]
[1] 198
But hey, that might just be because I redefined 'return' earlier:
> return
function(...){list(...)}
It is unlikely this is the case in rpart though...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cat with backspace and newline characters
On Thu, Nov 7, 2013 at 8:28 AM, Jari Oksanen wrote:
>
> On 07/11/2013, at 09:35 AM, Renaud Gaujoux wrote:
>
>> I agree that the handling of \b is not that strange, once one agrees
>> on what \b actually means, i.e. "go back one character" and not
>> "delete previous character".
It means, to paraphrase Humpty Dumpty from Alice in Wonderland,
whatever the terminal chooses it to mean. If you want to do something
meaningful and consistent across different terminals, you use termcap
or terminfo:
http://en.wikipedia.org/wiki/Termcap
http://en.wikipedia.org/wiki/Terminfo
or other abstractions probably built on that (eg 'ncurses').
> As a user DEC LA120 terminal I expect the following:
>
>> cat("a\b^\n")
> â
>>
>
> Everything else feels like a bug.
Oh noes! I don't have a terminfo entry for my DEC LA120!
I don't know what flavour of 'terminal' RStudio, the Windows GUI or
emacs-ess behave as and whether there's terminfo entries for them
Do any R packages link with termcap to do controlled screen output? H
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] contrib.url in non-interactive mode
On Fri, Feb 14, 2014 at 10:54 AM, Prof Brian Ripley wrote: > > It is up to you to set a default mirror: we have little idea where you > live (and it may not be where your email address suggests). Geolocation > of mirrors had been mooted but not implemented (and in a corporate > setting is not 100% reliable). The whole point of mirrors is to spread > the load: without them there would be no CRAN as the main host would not > allow the traffic. > > The RStudio CRAN mirror uses Amazon's CDN to achieve a degree of geographic convenience: http://blog.rstudio.org/2013/06/10/rstudio-cran-mirror/ As far as I know all the other CRAN mirrors are geographically nailed down and your data will come out of that server in that data centre wherever you and it may be. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Constructor/extractor.
On Tue, Mar 4, 2014 at 1:47 AM, Rolf Turner wrote: > > > Questions: > == > > > (2) Even if there are no such functions, is there anything intrinsically > *wrong* with having a function possessing this somewhat schizophrenic > nature? Is it likely to cause confusion, induce syntactical mistakes, > create errors, or produce wrong results? > > Any thoughts, comments, insights or suggestions gratefully received. > I don't see why you can't conceptually think of w = owin(some_ppp_object) as an owin "Constructor" rather than an "Accessor". Its "constructing" (and returning) an owin from an object, it just happens to be as simple as getting a component from that object. The raster package has the 'extent' function - you can create an extent with extent(xmin,xmax,,,etc), get the extent of a raster with extent(r), or set the extent of a raster with extent(r1) <- extent(r2), so I don't see any problem with: w1 = owin(poly=...) # construct polygon owin ppp1 = ppp(x,y,window=w1) ppp2 = ppp(x,y, window=owin(ppp1)) # construct window from ppp object owin(ppp1) = owin(ppp2) # give ppp1 the owin of ppp2 That all reads pretty nicely. As long as owin(...) returns an observation window and owin<-(...) assigns an observation window to an object that can validly have one, I don't think you can go wrong. I've probably already tried to do "owin(ppp1)=..." a few times... Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: API design of package "modules"
On Mon, Apr 28, 2014 at 2:55 PM, Konrad Rudolph <
konrad.rudolph+r-de...@gmail.com> wrote:
>
> So this is my question: what do other people think? Which is the most
> useful and least confusing alternative from the usersâ perspective?
>
The most useful is alternative is "write packages".
The overhead is minimal (install devtools, create("foo"); repeat {
load_all("foo") ; edit; until_bugs==0} ). Reloading a package is a
one-liner, you can't get more minimal.
And with that you get a structure for documentation, a metadata standard,
a wide range of sanity checks, and the option to push to CRAN or github for
distribution. What you don't get is hierarchies.
Can we get a hierarchy into base packages? That's the real question, and
if answered I think it makes your module package redundant. I'd love to see
a hierarchy with a colon-separator or something, so if I have a package
with foo/R/thing.R and foo/R/this/thing.R I can do:
require(foo)
thing()
this:thing()
or similar
I do like your approach of returning an object that provides an access to
the functions without side-effects, but the masses are so brainwashed into
thinking that require(foo) can put an unknown number of unknown-named
functions into your search list that I don't think it will ever get into
base R...
Note I did once write a simple file loader to avoid using source - it used
sys.source to load files into an environment on the search path, storing
the folder name so that it could be easily reloaded, but then devtools came
along...
If you want your module package to succeed you are going to have to
duplicate all the good stuff in packages - documentation, metadata,
distribution (trivial: zip/unzip/pull/push), and then another problem -
people will grow out of it - they'll start writing C and Fortran code.
Going to support that? devtools already does.
Barry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] precedence (was 'historical NA question')
On Wed, May 7, 2014 at 11:00 PM, Duncan Murdoch wrote: > > > Is there a language where "- 2^2" gives a different answer than "-2^2"? > (Substitute ** or any other exponentiation operator for ^ if you > like.) This is important, because I'd like to avoid ever attempting any > important calculation in that language. > I just checked that with javascript, and it gives the same answer so that's okay. I tried JS because it has some fun things to do with numbers (especially if you let it coerce strings): > "2" - "1" 1 > "2" + "1" "21" The Javascript Best Practices Document[1] says you should never use the plus sign for arithmetic addition, instead use a double negative and rely on "subtract" converting to numeric: > "2"- -"1" 3 Given that web pages written with JS get all their data from web content as strings, this can happen more often than you think. This is an example to show to everyone who says "Can we use + to concatenate strings in R please!?". Barry [1] A completely fictional publication I invented just now, but hey, I've seen worse than this. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setting environmental variable inside R function to call C function
What does c_fun look like? Here's mine:
#include
#include
void c_fun(){
printf("TMP is %s\n", getenv("TMP"));
}
and I then do this at the shell prompt:
R CMD SHLIB c_fun.c
and this at the R prompt:
dyn.load("c_fun.so")
wrapper()
and I get:
> wrapper()
[1] "A"
TMP is A
list()
Is that not what you want?
tldr; works for me.
On Tue, Jun 3, 2014 at 5:55 PM, Bowen Meng wrote:
> wrapper <- function(){
> Sys.setenv(TMP="A")
> print(Sys.getenv("TMP"))
>
> .C("c_fun")
> }
>
>
> As the example above, I hope to set an env var $TMP inside the R function
> "wrapper", which affects the functionality of the C function call "c_fun".
> Also the print line shows that $TMP is set to be "A", but the function call
> of "c_fun" was not affected.
>
> Does anyone know why and how to correctly set the env var for subsequent
> functions?
>
> Thanks,
> BW
>
> [[alternative HTML version deleted]]
>
> __
> 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] Listing Packages in Depends or Imports
On Fri, Jun 27, 2014 at 3:00 AM, Dario Strbenac wrote: > Hello, > > The Writing R Extensions manual gives confusing advice. Compare > > Packages listed in imports or importFrom directives in the NAMESPACE file > should almost always be in ‘Imports’ and not ‘Depends’. > > with > > Almost always packages mentioned in ‘Depends’ should also be imported from in > the NAMESPACE file Why is that confusing? Its perfectly logical. First line says that packages imported in the NAMESPACE should usually be in "Imports" in the DESCRIPTION. It implies there are special cases when "Depends" may be correctly used. Second line is that packages that are listed as Depends in DESCRIPTION should usually be imported in the NAMESPACE file, but implies there may be exceptions - you might correctly have a "Depends" that doesn't have an import in the NAMESPACE. In themselves, those two statements are perfectly logical and consistent. As an attempt to explain **when** you'd put a reference in Depends or Imports or why you'd use one of those get-out exceptions, it makes no claims! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why R-project source code is not on Github
On Thu, Aug 21, 2014 at 11:40 AM, Marc Schwartz wrote: > Your suggestion to move to Github is perhaps based upon a false premise, that > the R community at large has the ability to directly post code/patches to the > official distribution. That's not the false premise here. This is: "one simply can't ignore Github ,where collaboration is at it's best" - Gaurav Sehrawat speaking as someone often labelled a git[hub]-fanboy, even I can find reasons to debate this statement. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
And if, like me, you always forget which of Depends and Imports is the one you are supposed to be using, the mnemonic device is "DEPends is DEPrecated[1], IMPorts is IMPortant." Barry [1] kinda. On Thu, Aug 28, 2014 at 4:33 AM, Gavin Simpson wrote: > On Aug 27, 2014 5:24 PM, "Hadley Wickham" > >> I'd say: Depends is a historical artefact from ye old days before >> package namespaces. Apart from depending on a specific version of R, >> you should basically never use depends. (The one exception is, as >> mentioned in R-exts, if you're writing something like latticeExtras >> that doesn't make sense unless lattice is already loaded). > > Keeping this nuance in mind when when discussing Depends vs Imports is > important so as to not suggest that there isn't any reason to use Depends > any longer. > > I am in full agreement that its use should be limited to exceptional > situations, and have modified my packages accordingly. > > Cheers, > > G > >> > This check (whilst having found some things I should have imported and >> > didn't - which is a good thing!) seems to be circumventing the > intention of >> > having something in Depends. Is Depends going to go away? >> >> I don't think it's going to go away anytime soon, but you should >> consider it to be largely deprecated and you should avoid it wherever >> possible. >> >> >> (And really you shouldn't have any packages in depends, they should >> >> all be in imports) >> > >> > I disagree with *any*; having say vegan loaded when one is using > analogue is >> > a design decision as the latter borrows heavily from and builds upon > vegan. >> > In general I have moved packages that didn't need to be in Depends into >> > Imports; in the version I am currently doing final tweaks on before it > goes >> > to CRAN I have remove all but vegan from Depends. >> >> I think that is a reasonable use case for depends. Here's the exact >> text from R-exts: "Field ‘Depends’ should nowadays be used rarely, >> only for packages which are intended to be put on the search path to >> make their facilities available to the end user (and not to the >> package itself): for example it makes sense that a user of package >> latticeExtra would want the functions of package lattice made >> available." >> >> Personally I avoid even this use, requiring users of my packages to be >> explicit about exactly what packages are on the search path. You are >> of course welcome to your own approach, but I think you'll find it >> will become more and more difficult to maintain in time. I recommend >> that you bite the bullet now. >> >> Put another way, packages should be extremely conservative about >> global side effects (and modifying the search path is such a >> side-effect) >> >> Hadley >> >> -- >> http://had.co.nz/ > > [[alternative HTML version deleted]] > > __ > 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] Intel Fortran compiler returns a -1 TRUE value
I have access to a cluster on which I have been supplied with R 3.1.0 which
appears to have been built using the intel compiler tools.
The following minimal Fortran file:
subroutine truth(lind)
logical lind
lind = .TRUE.
end
Compiles thusly:
arcadia> R CMD SHLIB truth.f
ifort -fpic -O3 -xHOST -axCORE-AVX-I -fp-model precise -c truth.f -o
truth.o
ifort: command line warning #10212: -fp-model precise evaluates in source
precision with Fortran.
icc -std=gnu99 -shared -L/usr/local/lib64 -o truth.so truth.o -lifport
-lifcore -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl
And runs so:
> dyn.load("truth.so")
> z = .Fortran("truth",as.logical(TRUE))
> z[[1]]
[1] TRUE
> as.numeric(z[[1]])
[1] -1
> z[[1]] == TRUE
[1] FALSE
> all(z[[1]])
[1] TRUE
> identical(z[[1]],TRUE)
[1] FALSE
The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
conversion to -1 is most unusual, every other system I've tried converts to
+1.
So wrong compiler flag on build? User error - never try comparing
truthy values, as with the various flavours of NA? Or something else?
If its a compiler/config problem I'll pass it on to the cluster admin -
I've had a good look for stuff on building R on Intel compilers, nothing
stood out. I might try building R myself this afternoon but as I implied I
don't have admin on this cluster so I might have to track down a bunch of
library sources to build R from source.
If its a user error then I'll track down every instance of "if(foo==TRUE)"
and shoot it, and it would be nice to have a note in ?TRUE
Some useful info:
> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)
arcadia> ifort -v
ifort version 13.0.0
Thanks
Barry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch wrote: > > This appears to be user error. According to Writing R Extensions, the > Fortran type corresponding to R logical is INTEGER, not LOGICAL. > Oh yes, a very old and long-standing user error. I assume the CRAN checks don't check this. Has it ever been okay to pass logicals to Fortran? I shall inform the package maintainer Thanks Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On Tue, Sep 30, 2014 at 6:25 PM, William Dunlap wrote: > In S+ and S it was valid to pass logicals to .Fortran, where they got > mapped into the > appropriate bit pattern. (The trouble was that 'appropriate' was > compiled into the program - > so you were locked into our compiler vendor's choice). Passing them > between Fortran > code and C code has always been a problem (as has passing character > data between them). > That makes sense. The code was originally written for S-plus, and the accompanying R code is still in files with a .S extension The maintainer has now fixed it. Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On Thu, Oct 2, 2014 at 4:25 PM, Ei-ji Nakama wrote: > Hello > > > The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in > > all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric > > conversion to -1 is most unusual, every other system I've tried converts > to > > +1. > > Please read the -fpscomp logicals option of ifort. > Wow that's an interesting read, and the line "Intel recommends that you avoid coding practices that depend on the internal representation of LOGICAL values" says it all with regard to R and Fortran LOGICALS, I think! Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?
On Fri, Dec 12, 2014 at 12:34 PM, Jan Kim wrote:
> it's just a matter of time that people get characters into their code that
> are different but indistinguishable in the font they use (I've seen this
> with \H{o} rather than a \"{o}), and mega-personmonths are wasted puzzling
> over tracking down these problems.
Then R should ban variable names from having 'l', 'i', '1', '0' and
'O' in them!
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how useful could be a fast and embedded database for the R community?
On Wed, Dec 24, 2014 at 7:37 PM, joanv wrote: > I'm sorry, but I cannot show code. Then can you stop using the word "release". To release means to let something go, preferably out into the wild. I can't even find a binary "release" on that site. Call it the first "version" if you want, but not "release". I'm sure I'm not the only one wondering where this "release" is downloadable in some form. > For the moment, this project is not open > source, it has costs a lot of effort, and first of all, I have to find a way > to recover the investment. If I find a way to recover the investment, > compatible with an open source way of business, the project will be open > source, but first of all, I have to find the "way". You say the "Open Spartacus" project [http://www.openspartacus.org/] from which VulcanDB came failed "Due to the lack of funding". What was your personal relationship with that project? In what way, apart from in name, was that "Open"? I can't find source code or binary releases. Just a fancy single-page website with *all* the buzzwords. Does this failure not teach you anything? The R project and its leading lights are very proud of the open nature of R, and so you will be talking to strong proponents of open source software here. You've presented a project with no source or binary release, no documentation, no API or specification, nothing. No more than vapourware ever gives us. And then > Please, you can check the benchmark of the first release. There are not a > lot of information about the benchmark, because as I said before, some > information is sensitive to be published, for the moment. ... you ask *us* to check *your* benchmark? How? We have no idea exactly what you tested, and benchmark comparisons *depend* on that. > Of course, I would like this project to be open source, but if has to find > "the way", and ideas are welcome! Release early, release often. The only way other R users are going to be interested is to see the source, or at the very least to see the proposed API and be able to discuss this. I think you will find few friends here until you do. Otherwise I suggest you jazz up your benchmarks into a pseudo-technical paper with some 3d bar graphs and wave it under the noses of idiot venture capitalists until one of them throws some money at you. Good luck! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to make a true binary package?
On Tue, Oct 11, 2011 at 6:09 PM, A Zege wrote: > OK, gentlemen, i agree with you in general. I was not talking about a general > purpose, general use package that one prepares for CRAN. I am sure you are > familiar professionally or can imagine situations where you need to > demonstrate a solution to a specific task without fully disclosing the > details -- sometimes even hard core open source adherents need to sacrifice > desire for openness for some prosaic purposes, like getting paid :). > Compilable languages give an easy solution of a binary code. It sounds like > if one wants true binary, he has to recode in C++. I thought it's possible > in R as well, i thought this was discussed even as a default behavior for > next version of R to make stuff go faster. Maybe not. Thanks, anyway. > [deja vu all over again] What you seem to want to do is code obfuscation. With C, the obfuscation is caused by it being turned into machine code instructions, making exact reconstruction of the C source impossible, but reconstruction of the code as assembly language and hence reverse engineering very possible. With R, there is no compilation to machine code, so plain R source code has to be available to the R interpreter [exception: see Simon's talk of bytecode]. Any encryption you put on has to be decrypted by the user in order to run it. I've said this a few times on R-help and maybe R-devel too. If someone is offering to pay you, then if you tell them they can see the source code then they should want to pay you more. There's also nothing to stop you putting a restrictive license on your source code - including clauses like 'if you look at the contents of any *.R files you are in breach of this license'. These things might even stand up in court. Barry 'Not a lawyer' Rowlingson __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in rank(), order(), is.unsorted() on character vector
2011/12/7 Hervé Pagès : > rank(xa) See help(Comparison), specifically: "Beware of making _any_ assumptions about the collation order" followed by "Collation of non-letters (spaces, punctuation signs, hyphens, fractions and so on) is even more problematic." Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in rank(), order(), is.unsorted() on character vector
2011/12/7 Joris Meys : > @Barry : regardless of whether '_' comes before or after '1' , it > should be consistent. Adding an 'a' shouldn't shift '_' from before > '1' to between '1' and '2', that's clearly an error. The help files > are not stating anything about that. That's an assumption. The help pages are quite clear about making assumptions. The only way this could be a 'bug' is if you can show that the sort order in R is different from the lexicographic sort order using the collating sequence of the locale in use. But even my command line 'sort' agrees: $ sort < f1.txt _1_ 1_9 2_9 now add the trailing a: $ sort < f1.txt 1_9a _1_a 2_9a [ I had a thought maybe it was because _ is sometimes used to break thousands in numeric formats, but I can't get any obvious consistency out of that hypothesis ] Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] secure password token management method in R
On Wed, Dec 14, 2011 at 9:54 PM, Ni Wang wrote:
> hi, r developers, I am now working on a R function/package to handling
> online request with username and token/password.
>
> For security reasons, it's not so safe to store the username & token in
> persistent variables, since they'll be saved to disk when
> users save their workspace. Is there a secure way in R to handle the online
> password management? I have searched it online
> but didn't find any good suggestions. So I am trying my luck on this mail
> list.
If you save something to an environment that isnt the Global
Environment then R won't save it when you quit and save. Suggest you
save credentials in a list. Maybe something like this:
attach(list(username="mrbluesky",password="s3cr3t"),name="credentials")
then you just get user and password from the environment when needed:
get("username",envir=as.environment(credentials))
get("password",envir=as.environment(credentials))
saving the R workspace in the usual way (answering 'y' to Save
Workspace Image) won't save this data.
I have a vague memory of Splus possibly having a temporary
environment which would do what you want, but that doesn't seem to be
present in R...
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Saving nothing with save()
Scenario: Here I am working away in R. I've got results that prove global warming is anthropogenic and also the solution for producing limitless carbon-neutral energy from nuclear fusion. Its been a good day. So, I want to save my work. I don't want to overwrite my current .RData, so I save it to another file: save(file="prize.RData") # just need to email this to the Nobel committee q() Save workspace image? [y/n/c]: - "no" I don't want to save the workspace image, I just saved everything to "prize.RData". But gee, it did seem to do that quite quickly considering the volume of evidential data in my work. My unix shell prompt returns. Uh oh. See what I did there? I typed 'save' when I meant 'save.image'. What does that give me? A 42 byte, empty, latest.RData, and because there was no warning or error I quit without saving it again. Oops. Massive Data Loss. Is there any reason why save(file="file.RData") couldn't warn or error if you try and save nothing? There's no obvious check in the R code for save. Barry PS the above scenario is fictional. When did I last have a good day? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] secure password token management method in R
On Sun, Dec 18, 2011 at 1:28 AM, Paul Gilbert wrote: > One way this is often done is to have this information in a file that only > the owner can read. For example, mysql uses a file .my.cnf (in Windows it > may have a different name). The code then just reads the information from > the file. To guard against user carelessness, I think mysql will not use it > if anyone other than the user has read permission on the file. Of the > various options for passing user/password information, I think this is > general considered one of the better ways. If anyone has a large chunk of spare time on their hands they could implement an R interface to the Gnome Keyring and store credentials in there. I think under the hood it uses dbus so first implement dbus in R. Or just call some code with system()... gnome keyring API: http://live.gnome.org/GnomeKeyring/StoringPasswords command line interface: https://launchpad.net/gkeyring Probably getting a bit over the top now. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Saving nothing with save()
On Tue, Dec 20, 2011 at 6:40 PM, Martin Maechler wrote: > I've now changed the patch to only warn and only in the case > when the 'list' argument is missing(.). > > Martin Thanks Martin, that sounds great. This came about from a question on Stack Overflow, where a user was loading an R Data file and seemingly there was nothing in it, and there were no warnings. I suspected maybe there really was nothing in it, and discovered an easy way to create empty R Data files without really trying. Turns out her file was over 400k bytes long and once she reinstalled R [yikes] it loaded... What was the real problem? Well we never found out! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Task views (was: Re: [R] Schwefel Function Optimization)
On Sat, Feb 11, 2012 at 5:55 PM, Patrick Burns wrote: > Now it could be that people are not trying > very hard to solve their own problems, but > to be fair it is a pretty gruelling process > to find the Task Views. > > May I suggest that there be a "Task Views" item > on the left sidebar of the R website in the > Documentation section? > I'd go further, and suggest that the list of Task Views appears on the home page of www.r-project.org under the heading "Look at all these things you can do with R". (Maybe to replace the 8 year old clustering graphic (or maybe someone could do something in ggplot2 that looks nice n shiny?) ) "Task Views" (stupid name, who's idea was that?) are an absolute GEM and shouldn't be slotted between 'What's New?' and "Search" on CRAN mirror sites. The CRAN Task Views page doesn't even say what "Task Views" are. Here's some text that might help: "Task Views are short documents outlining the functionality of R in a given field or methodology. Since most of R's power comes from add-on packages downloaded from CRAN, Task Views tend to concentrate on summarising the packages that are relevant. If you ever find yourself thinking 'how do I do X in R?' then the list of Task Views should be your first stop." Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Jazzing up the Task Views index page
A little while ago here we had a short discussion about Task Views - I think ignited by someone saying 'how many times do I have to say "have you read the Optimisation Task View?"?' and I poured some fuel on that fire by saying "Task Views" was a stupid name. Anyway, I did say that Task Views were rather brilliant, but were let down by their hidden position on the R web sites (tucked away as the third element of a sub-menu of a CRAN mirror site linked to by the CRAN link from the Download menu on the main R home page). The index page is rather plain, so I designed a more engaging one. The result of my effort is now here: http://www.maths.lancs.ac.uk/~rowlings/R/TaskViews/ Having done that, I even considered that something like that could replace the R Homepage. Giving new visitors an idea of the vast range of techniques and application areas available in R would seem to be better than the current graphic which has been there since perhaps 2004. Comments, thoughts, flames, etc? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Jazzing up the Task Views index page
On Wed, Feb 22, 2012 at 3:34 PM, Joshua Wiley wrote: > Barry, is this a test/example only or would you plan on keeping > something like that on your site even if it is not adopted for cran > task views? If it is not adopted elsewhere and you are willing to > maintain it, I would like to link to it. It's really only a test, partly for fun, partly to try and kick up some of the dust on the R web pages. There's been a few comments about that, for sure. The main R web pages are becoming secondary to other community sites for information on R and packages and so on. I know it is essentially maintained by the developers primarily for the developers (as is R itself) but at some point the users will take over - as they are with the community sites springing up. However, it would be nice if www.r-project.org took you to a lively, engaging web site with twitter feeds and google +1 buttons and latest news postings. And didn't use framesets. There's also the issue of CRAN and its mirrors. Mirror technology is so last century - the way to do these things now is via CDNs - content delivery networks. You do magic redirection via http 302 responses, or metalinks. It enables better logging, better resilience. All it needs is a running instance of MirrorBrain. Or just stick .nyud.net on the end of the URL and have everything magically cached and proxied by the Coral cache network. The inertia to all this is 'well, it works okay at the moment'. But why is 'okay' okay, when 'better' is better? Anyway, how many of you played 'Top Trumps' when you were kids? My Task Views index reminded me of it, so I just spent an hour grabbing some stats and formatting them: http://www.maths.lancs.ac.uk/~rowlings/R/TaskViews/card.html The inaugural Task Views Top Trumps World Championship will be held in Nashville in June... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] csv version of data in an R object
On Sat, Apr 21, 2012 at 3:28 PM, Max Kuhn wrote: > For a package, I need to write a csv version of a data set to an R > object. Right now, I use: > > out <- capture.output( > write.table(x, > sep = ",", > na = "?", > file = "", > quote = FALSE, > row.names = FALSE, > col.names = FALSE)) > > To me, this is fairly slow; 131 seconds for a data frame with 8100 > rows and 1400 columns. > > The data will be in a data frame; I know write.table() would be faster > with a matrix. I was looking into converting the data frame to a > character matrix using as.matrix() or, better yet, format() prior to > the call above. However, I'm not sure what an appropriate value of > 'digits' should be so that the character version of numeric data has > acceptable fidelity. > > I also tried using a text connection and sink() as shown in > ?textConnection but there was no speedup. > You could try a loop over each row, and use 'paste' to join each element in a row by commas. Then use 'paste' again to join everything you've got (a vector of rows) by a '\n' character. something like: paste(apply(x,1,paste,collapse=","),collapse="\n") # untested you probably also want to stick a final \n on it. Is it faster? I don't know! Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chown, chgrp?
On Tue, Aug 14, 2012 at 9:30 PM, Hadley Wickham wrote: > Hi all, > > Is there an R wrapper for chown/chgrp (a la Sys.chmod)? I couldn't > find one with a few minutes of searching, but it seems like a curious > omission. A recursive grep of an R-dev source tree I had lying around couldn't find one in a few seconds. I'm not sure its a 'curious' omission, since its something normal users[1] can't do, and who runs R as root? Barry [1] Or at least normal normal users. There might be special normal users with certain chown permissions... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chown, chgrp?
On Wed, Aug 15, 2012 at 2:47 PM, Simon Urbanek wrote: > > ... and moreover with the increasing adoption of ACL on unix and > non-existence of uid/gid on Windows this is more an archaic curiosity so I > don't think it makes sense to add it at this point. > It does however raise the question, "What is Hadley up to now?" :) Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SystemRequirements’ field
I see three references to systemRequirements in Writing R Extensions. The one you list in your last email, this one: "If your package requires one of these interpreters or an extension then this should be declared in the ‘SystemRequirements’ field of its DESCRIPTION file." [for listing interpreters to run scripts] and "If you really must assume GNU make, declare it in the DESCRIPTON file by SystemRequirements: GNU make" A grep of a complete R 2.15-2 source tree doesn't show it being used either. It's mentioned in the OONEWS file for R 1.7.0 "It is now recommended to use the 'SystemRequirements:' field in the DESCRIPTION file for specifying dependencies external to the R system." Grepping all the DESCRIPTION files on my work box shows such values for that field as: "GRASS (>=6.3)" "An ODBC3 driver manager and drivers" "libxml2 (>=2.6.3)" "OpenGL, GLU Library, zlib (optional), libpng) "for building from source: GDAL >= 1.6.0 library" some of which look pretty free-form descriptive to me. Hope that's a bit more useful than 'No'. On Wed, Dec 12, 2012 at 7:55 PM, Paul Gilbert wrote: > > > On 12-12-12 02:19 PM, Prof Brian Ripley wrote: >> On 12/12/2012 18:33, Paul Gilbert wrote: >>> Am I correct in thinking that the ‘SystemRequirements’ field in a >>> package DESCRIPTION file is purely descriptive, there are no standard >>> elements that can be extracted by parsing it and used automatically? >> >> No. >> > > Where can I find more details? The section "The DESCRIPTION file" in > "Writing R Extensions" says only: > > Other dependencies (external to the R system) should be listed in > the ‘SystemRequirements’ field, possibly amplified in a separate > README file. > > Thanks, > Paul > > __ > 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] CRAN task views: markdown? better .CSS?
On Thu, Jan 31, 2013 at 4:28 PM, Yihui Xie wrote: > See this page by Barry Rowlingson: > https://stat.ethz.ch/pipermail/r-devel/2012-February/063338.html Sadly that page is just the lipstick on a pig. Underneath, its still a pig. > Given that CRAN maintainers do not even use JavaScript, I bet CSS does > not matter either; plain text is plain good. I think we all know that the whole of www.r-project.org could do with a revamp and that large chunks of the CRAN infrastructure would benefit from a redesign. But at the moment, it all kinda works, its just a bit annoying in places, and we put up with it because the effort to make it more functional or shiny (no, not package:shiny) is a bit too much. Sometimes putting lipstick on the pig is enough... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why cannot `Rscript -e` accept an empty line?
On Sat, Mar 9, 2013 at 9:32 PM, Yihui Xie wrote:
> See the example below (under Ubuntu):
>
> $ Rscript -e '1' -e '2'
> [1] 1
> [1] 2
> $ Rscript -e '1' -e '' -e '2'
> ERROR: option '-e' requires an argument
> $ uname -a
> Linux xie 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
>
> Similar problem under Windows:
>
> Rscript -e "1" -e "" -e "2"
> [1] 1
> Error: object 'e' not found
> Execution halted
>
> I can certainly save the code in a script and run Rscript foo.R, but
> I'm curious why Rscript stops when the -e argument is an empty string.
There's some over-zealous argument parsing in the main R startup
shell script. You didn't try negative numbers, did you?
$ Rscript -e "-1"
ERROR: option '-e' requires an argument
$ Rscript -e "+1"
[1] 1
The R script strips anything starting with a - from the arg after -e
and throws that error if there's nothing left. The relevant lines are:
-e)
if test -n "`echo ${2} | ${SED} 's/^-.*//'`"; then
a=`echo "${2}" | ${SED} -e 's/ /~+~/g'`; shift
else
error "option '${1}' requires an argument"
fi
- now at least that's on Unix. The Windows problem looks like its
doing something else, and mashing some quotes up and passing 'e' as an
expression to one of the other -e options.
Not sure what the fix might be, except maybe for the user to always
wrap their expressions in curly brackets...
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snippets from other packages/ License
On Thu, Mar 14, 2013 at 8:34 AM, Felix Schönbrodt wrote: > Hello, > > I want to use a function from another package (which is GPL>=3), about 20 > lines of code, in my own package. > I somewhat hesitate to depend on the entire package just for this single > function, but of course I want to credit the original authors. > > What would be the best way to do that? Where should I put that credit? Or > should I proceed completely different? Why so shy about the name and location of this function? I think I've seen cases like this before, where a package has a handy little function that has use outside the context of the package. In that case I think the best thing is often for that function to be taken out of that package completely, and put in a new package, because it isn't so tightly coupled to the aims of the package. Obviously this is overkill for one function, but its possible there's a few functions, or that they are handy enough to belong somewhere else, such as the plotrix package if its a little plotting function, or in one of Hadley's packages if it has an underscore in the name. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD INSTALL fail deletes earlier versions
Just tried to update devtools for R 2.15.3, and after an error about
it only being available for 3.0.0, I found my previously good-enough
devtools had disappeared. Here's how it happens:
$ R --quiet
> require(devtools)
Loading required package: devtools
pac> packageDescription("devtools")$Version
[1] "1.1"
$ R CMD INSTALL devtools_1.2.99.tar.gz
* installing to library
‘/nobackup/rowlings/RLibrary/R/i486-pc-linux-gnu-library/2.15’
ERROR: this R is version 2.15.3, package 'devtools' requires R >= 3.0
* removing
‘/nobackup/rowlings/RLibrary/R/i486-pc-linux-gnu-library/2.15/devtools’
Oh well, I'll just carry on with the old...
$ R --quiet
> require(devtools)
Loading required package: devtools
Warning message:
In library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE, :
there is no package called ‘devtools’
Oh gee thanks. 1.2.99 wouldn't install, so you zapped my otherwise
perfectly good 1.1?
Feature? Bug? Fixed in 3.0.0 (can't see it in NEWS)?
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Subset of a 'table' divided by a 'table' is a 'table', but printed by 'print.default'
On Tue, Apr 30, 2013 at 10:49 AM, Duncan Murdoch wrote: > So it looks like the bug is in the implementation of "/". Either it > should drop the class, or it should set the object bit. > > The difference in printing between auto-printing and explicit printing > may be worth addressing, but really objects like ratio shouldn't exist, > so it's not surprising that they behave strangely. Also happens with *, if LHS is not a scalar: > c(1,1)*table(x) x A B 2 2 attr(,"class") [1] "table" > 1*table(x) x A B 2 2 - similar with + and -, but not unary + and -. Nice to see a bug in arithmetic operators that isn't covered by everyone screaming "FAQ 7.31!!!" Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] locking down R
On Sun, May 19, 2013 at 7:16 PM, Ben Bolker wrote: > >The workstations have no access to external networks, > nor to external media (thumb drives etc.) [information transfer to the > outside world is via shared drives that can be accessed by > administrators with network access]. > > * I stipulate that (1) the security policies don't make sense, Correct. If the machines aren't on an external network and have no removable media then this isn't about security from the outside hacker, its about trust. The organisation does not trust YOU. (2) > allowing users access to arbitrary shell commands should _not_ represent > a security risk on a well-administered, modern operating system (they're > running WinXP), When does WinXP go out of support? Even so, the PC isn't on the network right? So what's the security issue? Doesn't make sense. You can't stomp on other people's files. Would it matter if you could accidentally see other people's files because they set permissions loosely? How compartmentalised are the projects? (3) R probably offers many other avenues for system > access to a malicious user, even in the absence of shell access, > compilers, etc.. The 'malicious user' here is on the inside. The only way to get on the machine is to be physically there? Then a malicious user can only be a trusted user gone bad. A sufficiently malicious user with hardware access can (nearly) always break the thing open and get at the data (even if it comes down to reading data lines with a tap to get at unencrypted streams). Tell the security guys they need to lock the PCs up in a room and provide thin client access over a secure private network at once. Enjoy your new Windows Client Access License costs. Glad I don't work for someone like that. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Colour Schemes
I've been thinking hard about generating colour schemes for data. There's quite a bit of existing code scattered in various packages for playing with colours and colour palettes, but I can't find the sort of thing I'm after for applying colours to data... To my mind a colour scheme is a mapping from data values to colours. There's a multitude of such mappings depending on the nature of the data. For example, for a factor you might want to map levels to unique colours. For numbers that run from -4 to +2 you might want to use a diverging colour palette centred on zero. This might be continuous in some colour space or composed of a small number of discrete colours, each of which covers a range of values. Or it could be piecewise continuous as used in topographic maps - less than zero is blue, zero to 400 goes from sandy yellow to grassy green, 400 to 1000 goes from grassy green to rocky brown, then suddenly you hit the ice and 1000 and upwards is white. Or you could have a multivariate mapping where (x,y,z) -> (r,g,b,a) in complex and non-linear ways. I see a set of factory functions that return colour scheme mapping functions that map data to colours, so you'd do: # unique colour for each factor level scheme1 = exactColours(data$f,someColours) # data$f is a factor, someColours is a vector of colour values plot(data$x,data$y,col=scheme1(data$f)) # topological map colouring scheme2 = continuousColours(list(-1000,"blue",0,"sandYellow",400,"grassGreen",1000,"rockBrown",1000,"white",1)) # or something... plot(data$x,data$y,col=scheme2(data$height)) Now just because I can't find existing functions like this doesn't mean they don't exist. There's stuff in plotrix, colorspace, RColorBrewer etc for creating palettes but then the user is left to their own devices to map colours to data values. Does this kind of thing sound useful? Has it been done? Is it worth doing? Anybody got any better ideas? Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Colour Schemes
On Thu, May 21, 2009 at 2:18 PM, wrote: > Most of the plots where colour is typically used to signify a variable > already do map colours to data values. Take a look at help pages for > levelplot/contourplot/wireframe from the lattice package, and image from > base graphics. > > (The format is typically slightly different to your suggested > specification, though the principle is the same. The functions take a > vector of cut points, and a vector of colours.) The problem here is that the user doesn't have exact control of the mapping from value to colour. For example (using a slightly more safe-for-use-after-lunch version of the levelplot example grid): x <- seq(pi/4, 5 * pi, length.out = 100) y <- seq(pi/4, 5 * pi, length.out = 100) r <- as.vector(sqrt(outer(x^2, y^2, "+"))) grid <- expand.grid(x=x, y=y) grid$z <- r grid$z2 = r *0.5 Then I do: levelplot(z~x*y, grid, cuts = 5, col.regions=rainbow(5)) very nice, but suppose I want to show $r2 on the same colour scale, I can't just do: levelplot(z2~x*y, grid, cuts = 5, col.regions=rainbow(5)) because that looks the same as the first one since levelplot uses the whole colour range. The base graphics "image" function has zlim arguments which let you do: z=outer(1:10,1:10,"*") image(z) image(z/2, zlim=range(z)) but again, not obvious, and complex/impossible when using more sophisticated colour mappings. > There may be some utility in creating functions to generate these colour > maps outside of the plotting functions, if only so that the code can be > recycled for new functions. Exactly, it would make a new package. Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Colour Schemes
On Thu, May 21, 2009 at 5:29 PM, Deepayan Sarkar wrote: [oops I didnt reply-to-all] > But you could specify an explicit 'at' vector specifying the color > breakpoints: effectively, you want at = do.breaks(zlim, 5). > > lattice does have a function called 'level.colors' that factors out > the color assignment computation. > Yes, but these things are all at the wrong conceptual level. What you are constructing here is a function that maps value to colour, but keeping it as breaks and cut values and colours instead of representing it as a function. Wouldn't it be nicer to build a real function object and have that to pass around? ggplot uses a different approach, for example in ?scale_fill_gradient, but ggplot uses "+" to add the layer objects together to create a plot. Nice. ggplot does things pretty well. Perhaps if we scrap all the other graphics systems :) Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Scope problem?
I've just spent today trying to fix a Heisenbug...
this function returns a linear interpolator function:
interpOne <- function(xl,yl){
f = function(data){
t = (data-min(xl))/(max(xl)-min(xl))
return(min(yl)+t*(max(yl)-min(yl)))
}
return(f)
}
> k=interpOne(c(0,1),c(4,5))
> k(0.5)
[1] 4.5
and this function uses the above to return a function that returns a
piece-wise linear interpolator function:
mr <- function(){
parts = list()
ranges = rbind(c(0,1),c(1,2),c(2,3))
domains = rbind(c(3,4),c(5,6),c(2,8))
for(i in 1:length(ranges[,1])){
parts[[i]] = interpOne(ranges[i,],domains[i,])
}
f = function(d){
pos = sum(d>ranges[,1])
cat("using pos = ",pos,"\n")
return(parts[[pos]](d))
}
return(f)
}
m = mr()
The 'ranges' and 'domains' vectors describe the pieces. But this doesn't work:
> m(0.5)
using pos = 1
[1] -7
- but it should be 3.5 (since 0.5 is in the first piece, and that
then interpolates between 3 and 4). What about the other pieces:
> m(1.5)
using pos = 2
[1] -1
> m(2.5)
using pos = 3
[1] 5
- which looks like it's using the last set of range/domain pairs each
time. Curious, I thought.
So I thought I'd evaluate the functions as they are created in the
list to see what's going on. Change the loop to print out:
for(i in 1:length(ranges[,1])){
parts[[i]] = interpOne(ranges[i,],domains[i,])
cat("part ",i," at zero = ",parts[[i]](0),"\n")
}
and try:
> m=mr()
part 1 at zero = 3
part 2 at zero = 4
part 3 at zero = -10
looks good, those are the intercepts of my pieces... but now:
> m(0.5)
using pos = 1
[1] 3.5
> m(1.5)
using pos = 2
[1] 5.5
> m(2.5)
using pos = 3
[1] 5
Woah! It's now working! Trying to observe the thing changes it? A Heisenbug!
I can only think it's my misunderstanding of some aspect of R's
scoping and evaluation rules. Does evaluating the functions within
that loop cause a copy of some environment to be made, or a 'lazy
evaluation' to be evaluated? Or a 'promise' to be fulfilled? I don't
really understand those terms, I'd just hoped functions ran in the
environment they were created in. Seems sometimes they do, sometimes
they dont... What's going on?
R 2.9.0 on Ubuntu.
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Scope problem?
On Fri, May 22, 2009 at 6:04 PM, Duncan Murdoch wrote: > Putting force(xl); force(yl) into your interpOne definition (so they get > executed when interpOne is called, not just when the returned function is > called) should work. *sigh* yes, that looks like it. The help for "force" gives a more concise example. What I'd posted was actually a cut-down version of my original problem! I've not tested it yet, but other things I'd tried had removed the bug without me understanding why - such as reassinging the args to interpOne inside the function. Do any other languages work like this? Thanks Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot ignores type= "n" when x is factor (PR#13703)
On Tue, May 26, 2009 at 5:58 PM, Paul Johnson wrote:
> There's no mention of plot.factor in the plot help page.
Yes there is, but hidden slightly more than the planning application
for the destruction of the Earth ("It was on display in the bottom of
a locked filing cabinet stuck in a disused lavatory with a sign on the
door saying 'Beware of the Leopard'"[1]). Here it is:
See Also:
'plot.default', 'plot.formula' and other methods; 'points',
'lines', 'par'.
see that 'other methods'? That's it. That's a clue. That's our
'beware of the leopard'. So you need to know about methods...
> How about inserting this at the top of the help page for plot:
>
> If either x or y is a factor variable, the plot.factor method is
> called to determine the sort of graph to be drawn. If x and y are both
> numeric, the type argument determines the sort of graph to be drawn.
Ah, but something like that would need inserting at the top of just
about every function. R has 'generic' functions that call specific
functions for specific types of object. In two (or more) different
ways. I'm not sure if there's an easy way to say 'get me the help for
the specific method for this thing X when I do foo(X)'.
You can try: methods(class=class(factor(c(1,2,3,1 which will show
'plot.factor' as one of the possible things you can do with factor
objects. Then you can do help(plot.factor). You can also do
methods(plot) to show all the different classes that the generic plot
function can work on. But note these are 'S3' methods - once you hit
"S4" methods you'll need something else.
And you can hit S4 methods in cruel and unusual ways. For example:
> library(sp)
> plot
standardGeneric for "plot" defined from package "graphics"
function (x, y, ...)
standardGeneric("plot")
Methods may be defined for arguments: x, y
Use showMethods("plot") for currently available ones.
Ooh, let's try that:
> showMethods("plot")
Function: plot (package graphics)
x="ANY", y="ANY"
x="SpatialLines", y="missing"
x="Spatial", y="missing"
x="SpatialPoints", y="missing"
x="SpatialPolygons", y="missing"
- no mention of factor there. That's because the sp package has
fiddled with the generic plot function to make it S4-compatible. The
S3 methods still work, but now you get added S4 method goodness.
Yes, the plot function has changed in the middle of your R session.
And this isn't "mostly harmless[1]". Some code I wrote broke because
the new definition of 'plot' was evaluating the 'y' when I didn't want
it to. The previous definition didn't evaluate y until it got to my
generic function.
> If you did that, then you could answer my bug report with the
> criticism that I did not read ?plot.factor or that plot.factor can't
> do what I want. Otherwise, your response seems unkind and somewhat
> unreasonable. I have no way of knowing that plot.factor is even
> involved when I try to use the plot function.
Perhaps an unkind and unreasonable response serves to shock people
into remembering these things - people on the end of such treatment
don't seem to return to ask very many more questions...
Barry
[1] Hitchhikers' Guide To The Galaxy, Douglas Adams
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
