Re: [Rd] memory issues with new release (PR#9344)
>> spend more time on this. I really don't mind using the >previous version. Hello Derek, or upgrade to R 2.5.0dev; the execution of your code snippet is not hampered by memory issues: > sessionInfo() R version 2.5.0 Under development (unstable) (2006-10-10 r39600) i386-pc-mingw32 locale: LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY= German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 attached base packages: [1] "methods" "stats" "graphics" "grDevices" "datasets" "utils" [7] "base" other attached packages: fortunes "1.3-2" > My output with respect to memory.limit(NA) is the same as yours. Best, Bernhard >> Like you mentioned, probably just a function of the new >version requiring >> more memory. > > >Hmm, you might want to take a final look at the Windows FAQ 2.9. I am >still not quite convinced you're really getting more than the default >1.5 GB. > >Also, how much can you increase the problem size on 2.3.0 before it >breaks? If you can only go to say 39 or 40 variables, then there's >probably not much we can do. If it is orders of magnitude, then we may >have a real bug (or not: sometimes we fix bugs resulting from things >not being duplicated when they should have been, the fixed code then >uses more memory than the unfixed code.) > >=20 >> Thanks, >> Derek >>=20 >>=20 >>=20 >> On 06 Nov 2006 21:42:04 +0100, Peter Dalgaard ><[EMAIL PROTECTED]> >> wrote: >> > >> > "Derek Stephen Elmerick" <[EMAIL PROTECTED]> writes: >> > >> > > Thanks for the replies. Point taken regarding submission >protocol. I >> > have >> > > included a text file attachment that shows the R output >with version >> > 2.3.0and >> > > 2.4.0. A label distinguishing the version is included in >the comments. >> > > >> > > A quick background on the attached example. The dataset >has 650,000 >> > records >> > > and 32 variables. the response is dichotomous (0/1) and >i ran a logis= >tic >> > > model (i previously mentioned multinomial, but decided >to start simple >> > for >> > > the example). Covariates in the model may be continuous >or categorica= >l, >> > but >> > > all are numeric. You'll notice that the code is the same for both >> > versions; >> > > however, there is a memory error with the 2.3.0 version. >i ran this >> > several >> > > times and in different orders to make sure it was not >some sort of >> > hardware >> > > issue. >> > > >> > > If there is some sort of additional output that would be >helpful, I c= >an >> > > provide as well. Or, if there is nothing I can do, that >is fine also. >> > >> > I don't think it was ever possible to request 4GB on XP. >The version >> > difference might be caused by different response to >invalid input in >> > memory.limit(). What does memory.limit(NA) tell you after >the call to >> > memory.limit(4095) in the two versions? >> > >> > If that is not the reason: What is the *real* restriction >of memory on >> > your system? Do you actually have 4GB in your system (RAM+swap)? >> > >> > Your design matrix is on the order of 160 MB, so shouldn't be a >> > problem with a GB-sized workspace. However, three copies of it will >> > brush against 512 MB, and it's not unlikely to have that >many copies >> > around. >> > >> > >> > >> > > -Derek >> > > >> > > >> > > On 11/6/06, Kasper Daniel Hansen < >[EMAIL PROTECTED]> wrote: >> > > > >> > > > It would be helpful to produce a script that >reproduces the error on >> > > > your system. And include details on the size of your >data set and >> > > > what you are doing with it. It is unclear what >function is actually >> > > > causing the error and such. Really, in order to do >something about = >it >> > > > you need to show how to actually obtain the error. >> > > > >> > > > To my knowledge nothing _major_ has happened with the memory >> > > > consumption, but of course R could use slightly more memory for >> > > > specific purposes. >> > > > >> > > > But chances are that this is not really memory related but more >> > > > related to the functions your are using - perhaps a >bug or perhaps a >> > > > user error. >> > > > >> > > > Kasper >> > > > >> > > > On Nov 6, 2006, at 10:20 AM, Derek Stephen Elmerick wrote: >> > > > >> > > > > thanks for the friendly reply. i think my >description was fairly >> > > > > clear: i >> > > > > import a large dataset and run a model. using the >same dataset, t= >he >> > > > > process worked previously and it doesn't work now. if the new >> > > > > version of R >> > > > > requires more memory and this compromises some basic >data analyse= >s, >> > > > > i would >> > > > > label this as a bug. if this memory issue was >mentioned in the >> > > > > documentation, then i apologize. this email was >clearly not well >> > > > > received, >> > > > > so if there is a more appropriate place to post these sort of >> > > > > questions, >> > > > > that would be helpful. >> > > > > >> > > > > -derek >> > > > > >> > > > > >> > > > > >> > > > > >> >
[Rd] R freezes with text(...., srt = -1e-8) (PR#9347)
Full_Name: Emmanuel Paradis Version: 2.4.0 OS: Linux Submission from: (NULL) (193.49.41.124) Adding text to a plot makes R freeze if 'srt' is given a very small negative value, eg: plot(1, type = "n") text(1, 1, "some text", srt = -1e-8) But if 'srt = -1e-6' (or smaller) or 'srt = -1e-19' (or greater), this works. This seems to be OS-dependent: I observed this under Linux but not under Solaris (I was not able to test under Windows or MacOS). EP __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] too-large notches in boxplot (PR #7690)
> "Ben" == Ben Bolker <[EMAIL PROTECTED]>
> on Mon, 23 Jan 2006 14:37:18 -0500 writes:
Ben> PR #7690 points out that if the confidence intervals (+/-1.58
Ben> IQR/sqrt(n)) in a boxplot with notch=TRUE are larger than the
Ben> hinges -- which is most likely to happen for small n and asymmetric
Ben> distributions -- the resulting plot is ugly, e.g.:
set.seed(1001)
npts <- 5
X <- rnorm(2*npts,rep(3:4,each=npts),sd=1)
f <- factor(rep(1:2,each=npts))
boxplot(X~f)
boxplot(X~f,notch=TRUE)
Ben> I can imagine debate about what should be done in this case --
Ben> you could just say "don't do that", since the notches are based
Ben> on an asymptotic argument ... the diff below just truncates
Ben> the notches to the hinges, but produces a warning saying that the
Ben> notches have been truncated.
Ben> ?? what should the behavior be ??
And this has been mentioned again more recently (than January!)
and IIRC I'd argued that the plotting behavior should not be changed,
because of back-compatibility and "you get what you deserve" etc
OTOH, users should at least notice that something "unusual"
happens,
and I have used part of Ben's proposed patch to simply issue a
warning when the notches go beyond the hinges i.e. out side the
"box" of the boxplot.
new>> Warning message:
new>> some notches went outside hinges ('box'): maybe set notch=FALSE
I hope that this helps all those who where puzzled
by examples like the one above.
Martin Maechler, ETH Zurich
with thanks to Ben for his perseverance (:-)
Ben> the diff is against the 11 Jan version of R 2.3.0
Ben> *** newboxplot.R2006-01-23 14:32:12.0 -0500
Ben> --- oldboxplot.R2006-01-23 14:29:29.0 -0500
Ben> ***
Ben> *** 84,98
Ben> bplt <- function(x, wid, stats, out, conf, notch, xlog, i)
Ben> {
Ben> ## Draw single box plot
Ben> - conf.ok <- TRUE
Ben> - if(!any(is.na(stats))) {
Ben> - ## check for overlap of notches and hinges
Ben> - if (notch && (stats[2]>conf[1] || stats[4] - conf.ok <- FALSE
Ben> - conf[1] <- max(conf[1],stats[2])
Ben> - conf[2] <- min(conf[2],stats[4])
Ben> -}
Ben> ## stats = +/- Inf: polygon & segments should handle
Ben> ## Compute 'x + w' -- "correctly" in log-coord. case:
Ben> --- 84,91
Ben> bplt <- function(x, wid, stats, out, conf, notch, xlog, i)
Ben> {
Ben> ## Draw single box plot
Ben> + if(!any(is.na(stats))) {
Ben> ## stats = +/- Inf: polygon & segments should handle
Ben> ## Compute 'x + w' -- "correctly" in log-coord. case:
Ben> ***
Ben> *** 148,154
Ben> domain = NA)
Ben> }
Ben> }
Ben> - return(conf.ok)
Ben> } ## bplt
Ben> if(!is.list(z) || 0 == (n <- length(z$n)))
Ben> --- 141,146
Ben> ***
Ben> *** 239,252
Ben> xysegments <- segments
Ben> }
Ben> - conf.ok <- numeric(n)
Ben> for(i in 1:n)
Ben> ! conf.ok[i] <- bplt(at[i], wid=width[i],
Ben> stats= z$stats[,i],
Ben> out = z$out[z$group==i],
Ben> conf = z$conf[,i],
Ben> notch= notch, xlog = xlog, i = i)
Ben> ! if (any(!conf.ok)) warning("some confidence limits > hinges:
Ben> notches truncated")
Ben> axes <- is.null(pars$axes)
Ben> if(!axes) { axes <- pars$axes; pars$axes <- NULL }
Ben> if(axes) {
Ben> --- 231,243
Ben> xysegments <- segments
Ben> }
Ben> for(i in 1:n)
Ben> ! bplt(at[i], wid=width[i],
Ben> stats= z$stats[,i],
Ben> out = z$out[z$group==i],
Ben> conf = z$conf[,i],
Ben> notch= notch, xlog = xlog, i = i)
Ben> !
Ben> axes <- is.null(pars$axes)
Ben> if(!axes) { axes <- pars$axes; pars$axes <- NULL }
Ben> if(axes) {
Ben> --
Ben> 620B Bartram Hall[EMAIL PROTECTED]
Ben> Zoology Department, University of Florida
http://www.zoo.ufl.edu/bolker
Ben> Box 118525 (ph) 352-392-5697
Ben> Gainesville, FL 32611-8525 (fax) 352-392-3704
Ben> __
Ben> R-devel@r-project.org mailing list
Ben> 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] gc()$Vcells < 0 (PR#9345)
On Mon, 6 Nov 2006, Vladimir Dergachev wrote: > On Monday 06 November 2006 6:12 pm, [EMAIL PROTECTED] wrote: >> version.string Version 2.3.0 (2006-04-24) >> >>> x<-matrix(nrow=44000,ncol=48000) >>> y<-matrix(nrow=44000,ncol=48000) >>> z<-matrix(nrow=44000,ncol=48000) >>> gc() >> >> used(Mb) gc trigger(Mb) max used(Mb) >> Ncells 177801 9.5 40750021.8 3518.7 >> Vcells -1126881981 24170.6 NA 24173.4 NA 24170.6 >> > > Happens to me with versions 2.40 and 2.3.1. The culprit is this line > in src/main/memory.c: > >INTEGER(value)[1] = R_VSize - VHEAP_FREE(); > > Since the amount used is greater than 4G and INTEGER is 32bit long > (even on 64 bit machines) this returns (harmless) nonsense. That's not quite correct. The units here are Vcells (8 bytes), and integer() is signed, so this can happen only if more than 16Gb of heap is allocated. We are aware that we begin to hit problems at 16Gb: it is for example the maximum size of an R vector. Those objects are logical and so about 7.8Gb each: their length as vectors is 98% of the maximum possible. However, the first time we discussed it we thought it would be about 5 years before those limits would become important -- I think three of those years have since passed. > The megabyte value nearby is correct and gc trigger and max used fields are > marked as NA already. and now 'used' is also marked as NA in 2.4.0 patched. This is only a reporting issue. When I first used R it reported only numbers, and I added the Mb as a more comprehensible figure (especially for Ncells). I think it would be sensible now to only report these figures in Mb or Gb (and also the reports for gcinfo(TRUE)). The model behind the report actually pre-dates the GC change in 1.2.0. The 'Vcells' are nowadays the sum of all the allocations from VECSXPs (which include their headers), rather than the 'vector heap' (although some of the earlier terminology persists). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R freezes with text(...., srt = -1e-8) (PR#9347)
On 11/7/2006 5:35 AM, [EMAIL PROTECTED] wrote: > Full_Name: Emmanuel Paradis > Version: 2.4.0 > OS: Linux > Submission from: (NULL) (193.49.41.124) > > > Adding text to a plot makes R freeze if 'srt' is given a very small negative > value, eg: > > plot(1, type = "n") > text(1, 1, "some text", srt = -1e-8) > > But if 'srt = -1e-6' (or smaller) or 'srt = -1e-19' (or greater), this works. > > This seems to be OS-dependent: I observed this under Linux but not under > Solaris > (I was not able to test under Windows or MacOS). This looks like a duplicate of PR#9301, which was fixed a couple of weeks ago according to this NEWS entry: o Drawing X11 rotated text was buggy for VERY small (negative) angle of rotation. Reported by Ben Bolker. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to link to vignette from .Rd file
I am building a package for various noncentral hypergeometric distributions.
I want to include some heavy mathematical formulas. It appears that the
build and INSTALL commands produce only .chm files and not .pdf files
from my .Rd files under Windows. This means that it cannot show
complicated mathematical formulas.
The solution might be to include a .pdf file as a vignette. I tried
that, but I can't find any way to link to the .pdf file or access it
from any of the help facilities. The .pdf file is useless if the user
can't find it.
I have placed the .pdf file under inst\doc\ together with an index.html
file.
I have tried to link to the .pdf file from an .Rd file with
\link{packagename/doc/xxx.pdf}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to link to vignette from .Rd file
On 11/7/2006 8:51 AM, Agner Fog wrote:
> I am building a package for various noncentral hypergeometric distributions.
>
> I want to include some heavy mathematical formulas. It appears that the
> build and INSTALL commands produce only .chm files and not .pdf files
> from my .Rd files under Windows. This means that it cannot show
> complicated mathematical formulas.
>
> The solution might be to include a .pdf file as a vignette. I tried
> that, but I can't find any way to link to the .pdf file or access it
> from any of the help facilities. The .pdf file is useless if the user
> can't find it.
Yes, that's a major problem in the current R help system. You can give
the user code that would work to show the vignette, but there's no way
to create a live link to it.
There are a lot of problems with the help system, and vague plans to fix
them, but there are a lot of meta-problems as well: there is no
agreement on whether it should it be a complete rewrite or an
incremental fix, no agreement on exactly what the goals of the system
should be (e.g. should help("foo") try to guess what the user meant when
the exact topic "foo" was not found), there's more energy spent on
criticizing proposed changes than on implementing anything at all, and
there's nobody who has the time and energy to fight against all of this
to actually do anything about it.
Duncan Murdoch
> I have placed the .pdf file under inst\doc\ together with an index.html
> file.
> I have tried to link to the .pdf file from an .Rd file with
> \link{packagename/doc/xxx.pdf}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Crash when embedding R X11 windows
Dear R developers,
I've been experimenting with embedding R X11 windows into another application
using KDE's QXEmbed on linux. Attempting to do so will crash R (with R 2.4.0,
trunk, and I know the bug has been around in prior versions). I used to think
this was related to bug #848, but I'm not sure, if / how the solution
suggested there still applies to current versions of R.
After debugging, I came up with the following patch (in src/modules/X11):
Index: devX11.c
===
--- devX11.c(revision 39818)
+++ devX11.c(working copy)
@@ -586,8 +586,8 @@
if (event.xany.type == Expose) {
while(XCheckTypedEvent(display, Expose, &event))
;
- XFindContext(display, event.xexpose.window,
-devPtrContext, &temp);
+ if (XFindContext(display, event.xexpose.window,
+devPtrContext, &temp)) return;
dd = (NewDevDesc *) temp;
if (event.xexpose.count == 0)
do_update = 1;
@@ -595,8 +595,8 @@
else if (event.type == ConfigureNotify) {
while(XCheckTypedEvent(display, ConfigureNotify, &event))
;
- XFindContext(display, event.xconfigure.window,
-devPtrContext, &temp);
+ if (XFindContext(display, event.xconfigure.window,
+devPtrContext, &temp)) return;
dd = (NewDevDesc *) temp;
xd = (newX11Desc *) dd->deviceSpecific;
if (xd->windowWidth != event.xconfigure.width ||
@@ -614,8 +614,8 @@
else if ((event.type == ClientMessage) &&
(event.xclient.message_type == _XA_WM_PROTOCOLS))
if (!inclose && event.xclient.data.l[0] == protocol) {
- XFindContext(display, event.xclient.window,
-devPtrContext, &temp);
+ if (XFindContext(display, event.xclient.window,
+devPtrContext, &temp)) return;
dd = (NewDevDesc *) temp;
KillDevice((DevDesc*) GetDevice(devNumber((DevDesc*) dd)));
}
I'll have to admit, that I'm mostly clueless as far as X11-programming is
concerned, so the patch may not be entirely correct. It does fix the crash,
however, and should be along the right lines. The rationale is, that
apparently calls to XFindContext() may fail in the context of embedding the
X11 window. The patch simply checks the return value of XFindContext() for a
non-zero (i.e. error) value, and in that case drops out of the function.
Does this seem like a valid fix? Should I provide more info?
Regards
Thomas Friedrichsmeier
pgpKMLM5Olgw9.pgp
Description: PGP signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Getting the name of a SEXP type in package code?
Hi, Is there an alternative to type2char that is available for use in package code? It would be useful for producing more informative error messages. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R freezes with text(...., srt = -1e-8) (PR#9347)
Duncan Murdoch wrote: > On 11/7/2006 5:35 AM, [EMAIL PROTECTED] wrote: > >> Full_Name: Emmanuel Paradis >> Version: 2.4.0 >> OS: Linux >> Submission from: (NULL) (193.49.41.124) >> >> >> Adding text to a plot makes R freeze if 'srt' is given a very small >> negative >> value, eg: >> >> plot(1, type = "n") >> text(1, 1, "some text", srt = -1e-8) >> >> But if 'srt = -1e-6' (or smaller) or 'srt = -1e-19' (or greater), this >> works. >> >> This seems to be OS-dependent: I observed this under Linux but not >> under Solaris >> (I was not able to test under Windows or MacOS). > > > This looks like a duplicate of PR#9301, which was fixed a couple of > weeks ago according to this NEWS entry: > > o Drawing X11 rotated text was buggy for VERY small (negative) > angle of rotation. Reported by Ben Bolker. Yes! I only checked the Graphics section... (not the Graphics-fixed one). EP __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gc()$Vcells < 0 (PR#9345)
On Tuesday 07 November 2006 6:28 am, Prof Brian Ripley wrote: > On Mon, 6 Nov 2006, Vladimir Dergachev wrote: > > On Monday 06 November 2006 6:12 pm, [EMAIL PROTECTED] wrote: > >> version.string Version 2.3.0 (2006-04-24) > >> > >>> x<-matrix(nrow=44000,ncol=48000) > >>> y<-matrix(nrow=44000,ncol=48000) > >>> z<-matrix(nrow=44000,ncol=48000) > >>> gc() > >> > >> used(Mb) gc trigger(Mb) max used(Mb) > >> Ncells 177801 9.5 40750021.8 3518.7 > >> Vcells -1126881981 24170.6 NA 24173.4 NA 24170.6 > > > > Happens to me with versions 2.40 and 2.3.1. The culprit is this line > > in src/main/memory.c: > > > >INTEGER(value)[1] = R_VSize - VHEAP_FREE(); > > > > Since the amount used is greater than 4G and INTEGER is 32bit long > > (even on 64 bit machines) this returns (harmless) nonsense. > > That's not quite correct. The units here are Vcells (8 bytes), and > integer() is signed, so this can happen only if more than 16Gb of heap is > allocated. I see - thank you for the explanation ! > > We are aware that we begin to hit problems at 16Gb: it is for example the > maximum size of an R vector. Those objects are logical and so about 7.8Gb > each: their length as vectors is 98% of the maximum possible. However, > the first time we discussed it we thought it would be about 5 years before > those limits would become important -- I think three of those years have > since passed. > > > The megabyte value nearby is correct and gc trigger and max used fields > > are marked as NA already. > > and now 'used' is also marked as NA in 2.4.0 patched. Great, thank you ! > > This is only a reporting issue. When I first used R it reported only > numbers, and I added the Mb as a more comprehensible figure (especially > for Ncells). I think it would be sensible now to only report these > figures in Mb or Gb (and also the reports for gcinfo(TRUE)). Why not use KB ? This still preserves information about small allocations and raises the limit to 16 TB - surely at least 5 years off ! :) Alternatively, doubles should be able to hold the entire number, but this would require changes to how information is displayed. > > The model behind the report actually pre-dates the GC change in 1.2.0. > The 'Vcells' are nowadays the sum of all the allocations from VECSXPs > (which include their headers), rather than the 'vector heap' (although > some of the earlier terminology persists). I see. thank you ! Vladimir Dergachev __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to link to vignette from .Rd file
Duncan Murdoch wrote:
> On 11/7/2006 8:51 AM, Agner Fog wrote:
>
>> I am building a package for various noncentral hypergeometric distributions.
>>
>> I want to include some heavy mathematical formulas. It appears that the
>> build and INSTALL commands produce only .chm files and not .pdf files
>> from my .Rd files under Windows. This means that it cannot show
>> complicated mathematical formulas.
>>
>> The solution might be to include a .pdf file as a vignette. I tried
>> that, but I can't find any way to link to the .pdf file or access it
>> from any of the help facilities. The .pdf file is useless if the user
>> can't find it.
>>
>
> Yes, that's a major problem in the current R help system. You can give
> the user code that would work to show the vignette, but there's no way
> to create a live link to it.
>
The demo system can be used to compensate for limitations of the help
system.
You can display PDF files from any package subdirectory using a demo file
like this (named demo/ReadPkgDoc.R, and documented in demo/00Index):
# ReadPkgDoc.R -- Displays a PDF file as a demo
#
isWindows <- (Sys.info()['sysname'] == 'Windows')
file <- system.file("doc", "PkgManual.pdf", package="PkgName")
if(isWindows) { # Windows automatically finds executable based on file type.
system(paste("CMD /C ", file, "\n"))
} else { # Change this to use path to Adobe reader if desired.
system(paste("xpdf ", file, "\n"))
}
To create the PDF file from the Rd file use R CMD Rd2dvi, and dvipdf.
ds
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to link to vignette from .Rd file
On Tue, 2006-11-07 at 12:41 -0500, Dominick Samperi wrote: > Duncan Murdoch wrote: > > On 11/7/2006 8:51 AM, Agner Fog wrote: > > > >> I am building a package for various noncentral hypergeometric > >> distributions. > >> > >> I want to include some heavy mathematical formulas. It appears that the > >> build and INSTALL commands produce only .chm files and not .pdf files > >> from my .Rd files under Windows. This means that it cannot show > >> complicated mathematical formulas. > >> > >> The solution might be to include a .pdf file as a vignette. I tried > >> that, but I can't find any way to link to the .pdf file or access it > >> from any of the help facilities. The .pdf file is useless if the user > >> can't find it. > >> > > > > Yes, that's a major problem in the current R help system. You can give > > the user code that would work to show the vignette, but there's no way > > to create a live link to it. > > > To create the PDF file from the Rd file use R CMD Rd2dvi, and dvipdf. You can do this directly without dvipdf: R CMD Rd2dvi --pdf name_of_Rd_file.Rd G > > ds -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [t] +44 (0)20 7679 0522 ECRC & ENSIS, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting the name of a SEXP type in package code?
> "Seth" == Seth Falcon <[EMAIL PROTECTED]> > on Tue, 07 Nov 2006 06:55:06 -0800 writes: Seth> Hi, Seth> Is there an alternative to type2char that is available for use in Seth> package code? It would be useful for producing more informative error Seth> messages. I haven't looked closely, but I vaguely remember that I had thought in the past, (a version of) type2char() should be made part of R's API. Exactly because of the reason you give. A more sensible name for the exported function would probably be R_type2charor Rtype_to_char or Rtype_as_char If you are going to provide a patch (against R-devel), you'd ideally also include the corresponding entry in doc/manual/R-exts.texi ... (:-) Martin PS: I will be mostly absent from e-mail for the rest of the week. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] variable problem
Hi everyone,
I am not sure this is possible so I would be interested in your
responses. Say I have a variable 'v' with the string "myargument" in and
I have a function 'f' that takes this argument as follows;
f <- function( myargument=5 ) {
... does something...
}
Is there anyway I can say something like;
f( v=10 ) such that it will be evaluated as f( myargument=10 ).
I presume there may be some use eval and substitute but if someone could
point me in the right direction then that would be great.
The end idea is to have a list of m items, declared somewhere else, which
can be evaluated as particular arguments named after their list names
e.g
mylist <- list( "a"=1, "b"=2, "c"=3 )
which can be passed to a function taking arguments a,b, or c and it will
be able to evaluate them accordingly :
long hand this would evaluate to something like
f( a=mylist[["a"]] );
f( b=mylist[["b"]] );
f( c=mylist[["c"]] );
but I would have actually rewritten something like
for ( myvar in names( mylist ) ) {
f( some_clever_substitution_to_act_as_argument(myvar) =
mylist[[ myvar
]] );
}
I hope I have explained myself clearly enough, if not please say so and I
will try and give a better example.
Many thanks for your help
Tom
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable problem
On Tuesday 07 November 2006 3:28 pm, Tom McCallum wrote:
> Hi everyone,
Hi Tom,
Would this snippet work:
for(i in 1:length(mylist))do.call(f, mylist[i])
On the other hand it is not easy to see why you would want to call the
same function with differently named arguments - perhaps what you are really
trying to do has a different (and better) solution ?
best
Vladimir Dergachev
>
> I am not sure this is possible so I would be interested in your
> responses. Say I have a variable 'v' with the string "myargument" in and
> I have a function 'f' that takes this argument as follows;
>
> f <- function( myargument=5 ) {
>... does something...
> }
>
> Is there anyway I can say something like;
>
> f( v=10 ) such that it will be evaluated as f( myargument=10 ).
>
> I presume there may be some use eval and substitute but if someone could
> point me in the right direction then that would be great.
>
> The end idea is to have a list of m items, declared somewhere else, which
> can be evaluated as particular arguments named after their list names
>
> e.g
>
> mylist <- list( "a"=1, "b"=2, "c"=3 )
>
> which can be passed to a function taking arguments a,b, or c and it will
> be able to evaluate them accordingly :
>
> long hand this would evaluate to something like
> f( a=mylist[["a"]] );
> f( b=mylist[["b"]] );
> f( c=mylist[["c"]] );
>
> but I would have actually rewritten something like
> for ( myvar in names( mylist ) ) {
> f( some_clever_substitution_to_act_as_argument(myvar) =
> mylist[[ myvar
> ]] );
> }
>
> I hope I have explained myself clearly enough, if not please say so and I
> will try and give a better example.
>
> Many thanks for your help
>
> Tom
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] variable problem
Works like a charm - thank you very much.
Tom
On Tue, 07 Nov 2006 20:45:04 -, Vladimir Dergachev
<[EMAIL PROTECTED]> wrote:
> On Tuesday 07 November 2006 3:28 pm, Tom McCallum wrote:
>> Hi everyone,
>
> Hi Tom,
>
> Would this snippet work:
>
> for(i in 1:length(mylist))do.call(f, mylist[i])
>
> On the other hand it is not easy to see why you would want to call
> the
> same function with differently named arguments - perhaps what you are
> really
> trying to do has a different (and better) solution ?
>
>best
>
> Vladimir Dergachev
>
>>
>> I am not sure this is possible so I would be interested in your
>> responses. Say I have a variable 'v' with the string "myargument" in
>> and
>> I have a function 'f' that takes this argument as follows;
>>
>> f <- function( myargument=5 ) {
>>... does something...
>> }
>>
>> Is there anyway I can say something like;
>>
>> f( v=10 ) such that it will be evaluated as f( myargument=10 ).
>>
>> I presume there may be some use eval and substitute but if someone could
>> point me in the right direction then that would be great.
>>
>> The end idea is to have a list of m items, declared somewhere else,
>> which
>> can be evaluated as particular arguments named after their list names
>>
>> e.g
>>
>> mylist <- list( "a"=1, "b"=2, "c"=3 )
>>
>> which can be passed to a function taking arguments a,b, or c and it will
>> be able to evaluate them accordingly :
>>
>> long hand this would evaluate to something like
>> f( a=mylist[["a"]] );
>> f( b=mylist[["b"]] );
>> f( c=mylist[["c"]] );
>>
>> but I would have actually rewritten something like
>> for ( myvar in names( mylist ) ) {
>> f( some_clever_substitution_to_act_as_argument(myvar) =
>> mylist[[ myvar
>> ]] );
>> }
>>
>> I hope I have explained myself clearly enough, if not please say so and
>> I
>> will try and give a better example.
>>
>> Many thanks for your help
>>
>> Tom
>
--
Dr. Thomas McCallum
Systems Architect,
Level E Limited
ETTC, The King's Buildings
Mayfield Road,
Edinburgh EH9 3JL, UK
Work +44 (0) 131 472 4813
Fax: +44 (0) 131 472 4719
http://www.levelelimited.com
Email: [EMAIL PROTECTED]
Level E is a limited company incorporated in Scotland. The contents of
this e-mail are privileged and/or confidential. If you are not the
intended recipient, please
notify the sender and ensure this e-mail is deleted and not read, copied
or disclosed. It is your responsibility to scan this e-mail and any
attachments for
computer viruses or other defects. Level E does not accept liability for
any loss or damage which may result from this e-mail or any attachment.
E-mail is not secure
and can be intercepted, corrupted or amended. Level E does not accept
liability for errors or omissions arising as a result of interrupted or
defective transmission.
Any views, opinions, conclusions or other information in this e-mail which
do not relate to the business of Level E Limited are not authorised by
Level E. Unless
specifically stated and authorised by Level E, nothing in this e-mail
shall be taken to be an offer or acceptance of any contract of any nature.
E-mail entering or leaving Level E's system is subject to random
monitoring and recording.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to link to vignette from .Rd file
Dirk Eddelbuettel wrote:
> There is options("pdfviewer") -- at least under Unix. Maybe there is
> even an R call to use it on a file, employed by the help system?
> Dirk
Thanks,
Here is a more complete solution that can be turned into a general-purpose
function...
# Displays PDF file as an R demo
#
pkgName <- 'MyPackage'
pkgDir <- 'doc'
pdfFile <- 'MyPackageDoc.pdf'
isWindows <- (Sys.info()['sysname'] == 'Windows')
pkgLoc <- system.file(".", ".", package=pkgName)
pkgLoc <- substring(pkgLoc, 1, nchar(pkgLoc)-nchar(pkgName)-5)
file <- system.file(pkgDir, pdfFile, package=pkgName,lib.loc=pkgLoc)
if(isWindows) { # Windows automatically finds executable based on file type.
system(paste("CMD /C ", file, "\n"))
} else { # Change this to use path to Adobe reader if desired.
system(paste(options("pdfviewer"), file, "\n"))
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to link to vignette from .Rd file
This all seems very similar to the built-in "vignette" function; e.g.
vignette("grid")
Cheers,
Rich
On 11/8/06, Dominick Samperi <[EMAIL PROTECTED]> wrote:
> Dirk Eddelbuettel wrote:
> > There is options("pdfviewer") -- at least under Unix. Maybe there is
> > even an R call to use it on a file, employed by the help system?
> > Dirk
> Thanks,
> Here is a more complete solution that can be turned into a general-purpose
> function...
>
> # Displays PDF file as an R demo
> #
> pkgName <- 'MyPackage'
> pkgDir <- 'doc'
> pdfFile <- 'MyPackageDoc.pdf'
> isWindows <- (Sys.info()['sysname'] == 'Windows')
> pkgLoc <- system.file(".", ".", package=pkgName)
> pkgLoc <- substring(pkgLoc, 1, nchar(pkgLoc)-nchar(pkgName)-5)
> file <- system.file(pkgDir, pdfFile, package=pkgName,lib.loc=pkgLoc)
> if(isWindows) { # Windows automatically finds executable based on file type.
> system(paste("CMD /C ", file, "\n"))
> } else { # Change this to use path to Adobe reader if desired.
> system(paste(options("pdfviewer"), file, "\n"))
> }
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Rich FitzJohn
rich.fitzjohn gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Chi-squared test (PR#9350)
Full_Name: Sahotra Sarkar Version: 2.2.0 OS: Windows XP Submission from: (NULL) (128.83.34.44) This is not a bug: I'm just wondering why chisq.test does not allow the specification of the degree of freedom (df). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Chi-squared test (PR#9350)
(not cc'ed to R-bugs) If this is not a bug why do you abuse the bug report system to ask a simple question? Now a member of R-core has to use valuable time to handle this bug report, time that could be far more profitable spent making improvements to R (or spend it otherwise). This is incredible selfish behavior. Kasper On Nov 7, 2006, at 5:41 PM, [EMAIL PROTECTED] wrote: > Full_Name: Sahotra Sarkar > Version: 2.2.0 > OS: Windows XP > Submission from: (NULL) (128.83.34.44) > > > This is not a bug: I'm just wondering why chisq.test does not allow > the > specification of the degree of freedom (df). > > __ > 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] Getting the name of a SEXP type in package code?
type2char is itself a fairly recent addition (there is also type2str, which is older) that I found useful for improving messages in R itself. I have not encountered such a need in package code, but the function is exported. This is not a request to move type2char from Defn.h to Rinternals.h, and I don't understand why not: what else is needed? On Tue, 7 Nov 2006, Martin Maechler wrote: >> "Seth" == Seth Falcon <[EMAIL PROTECTED]> >> on Tue, 07 Nov 2006 06:55:06 -0800 writes: > >Seth> Hi, >Seth> Is there an alternative to type2char that is available for use in >Seth> package code? It would be useful for producing more informative > error >Seth> messages. > > I haven't looked closely, but I vaguely remember that I had > thought in the past, > (a version of) type2char() should be made part of R's API. > Exactly because of the reason you give. > > A more sensible name for the exported function would probably be > R_type2charor > Rtype_to_char or > Rtype_as_char It is exported as Rf_type2char. > If you are going to provide a patch (against R-devel), > you'd ideally also include the corresponding entry in > doc/manual/R-exts.texi ... (:-) > > Martin > > PS: I will be mostly absent from e-mail for the rest of the week. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gc()$Vcells < 0 (PR#9345)
On Tue, 7 Nov 2006, Vladimir Dergachev wrote: > On Tuesday 07 November 2006 6:28 am, Prof Brian Ripley wrote: >> On Mon, 6 Nov 2006, Vladimir Dergachev wrote: >>> On Monday 06 November 2006 6:12 pm, [EMAIL PROTECTED] wrote: version.string Version 2.3.0 (2006-04-24) > x<-matrix(nrow=44000,ncol=48000) > y<-matrix(nrow=44000,ncol=48000) > z<-matrix(nrow=44000,ncol=48000) > gc() used(Mb) gc trigger(Mb) max used(Mb) Ncells 177801 9.5 40750021.8 3518.7 Vcells -1126881981 24170.6 NA 24173.4 NA 24170.6 >>> >>> Happens to me with versions 2.40 and 2.3.1. The culprit is this line >>> in src/main/memory.c: >>> >>>INTEGER(value)[1] = R_VSize - VHEAP_FREE(); >>> >>> Since the amount used is greater than 4G and INTEGER is 32bit long >>> (even on 64 bit machines) this returns (harmless) nonsense. >> >> That's not quite correct. The units here are Vcells (8 bytes), and >> integer() is signed, so this can happen only if more than 16Gb of heap is >> allocated. > > I see - thank you for the explanation ! > >> >> We are aware that we begin to hit problems at 16Gb: it is for example the >> maximum size of an R vector. Those objects are logical and so about 7.8Gb >> each: their length as vectors is 98% of the maximum possible. However, >> the first time we discussed it we thought it would be about 5 years before >> those limits would become important -- I think three of those years have >> since passed. >> >>> The megabyte value nearby is correct and gc trigger and max used fields >>> are marked as NA already. >> >> and now 'used' is also marked as NA in 2.4.0 patched. > > Great, thank you ! > >> >> This is only a reporting issue. When I first used R it reported only >> numbers, and I added the Mb as a more comprehensible figure (especially >> for Ncells). I think it would be sensible now to only report these >> figures in Mb or Gb (and also the reports for gcinfo(TRUE)). > > Why not use KB ? This still preserves information about small allocations and > raises the limit to 16 TB - surely at least 5 years off ! :) We already use 0.1Mb: why would you have any need for more accuracy? > Alternatively, doubles should be able to hold the entire number, but this > would require changes to how information is displayed. Actually, no as the matrix returned is double. What it did require is some redesign of the internal code, but that had already been done in R-devel. I don't have access to a machine which can handle more than 16Gb of memory allocation, but it should be the case that in R-devel the actual values will be returned. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
