Re: [Rd] R Bug: write.table for matrix of more than 2, 147, 483, 648 elements
Hi Colton,
You could divide your write task into chunks that do not violate the 2^31-1
limit.
write.table has an append argument (default FALSE).
Figure out a row chunk size nri < nr such that nri * nc is under 2^31-1 and use
write.table() to write that out.
Then use
write.table( append = TRUE, )
for the next chunk of rows, looping over chunks until done. Two chunks will
get your 2.8 billion entries done.
Best
Steve
Steven McKinney, Ph.D.
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Tousey,
> Colton
> Sent: April-18-18 2:08 PM
> To: r-c...@r-project.org; simon.urba...@r-project.org; R-devel@r-
> project.org
> Subject: [Rd] R Bug: write.table for matrix of more than 2, 147, 483, 648
> elements
>
> Hello,
>
> I want to report a bug in R that is limiting my capabilities to export a
> matrix with write.csv or write.table with over 2,147,483,648 elements (C's
> int limit). I found this bug already reported about before: https://bugs.r-
> project.org/bugzilla/show_bug.cgi?id=17182. However, there appears to be no
> solution or fixes in upcoming R version releases.
>
> The error message is coming from the writetable part of the utils package
> in the io.c source code(https://svn.r-
> project.org/R/trunk/src/library/utils/src/io.c):
> /* quick integrity check */
> if(XLENGTH(x) != (R_len_t)nr * nc)
> error(_("corrupt matrix -- dims not not match
> length"));
>
> The issue is that nr*nc is an integer and the size of my matrix, 2.8
> billion elements, exceeds C's limit, so the check forces the code to fail.
>
> My version:
> > R.Version()
> $platform
> [1] "x86_64-w64-mingw32"
>
> $arch
> [1] "x86_64"
>
> $os
> [1] "mingw32"
>
> $system
> [1] "x86_64, mingw32"
>
> $status
> [1] ""
>
> $major
> [1] "3"
>
> $minor
> [1] "4.3"
>
> $year
> [1] "2017"
>
> $month
> [1] "11"
>
> $day
> [1] "30"
>
> $`svn rev`
> [1] "73796"
>
> $language
> [1] "R"
>
> $version.string
> [1] "R version 3.4.3 (2017-11-30)"
>
> $nickname
> [1] "Kite-Eating Tree"
>
> Thank you,
> Colton
>
>
> Colton Tousey
> Research Associate II
> P: 816.585.0300 E: colton.tou...@kc.frb.org
> FEDERAL RESERVE BANK OF KANSAS CITY
> 1 Memorial Drive * Kansas City, Missouri 64198 *
> www.kansascityfed.org
>
> [[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] R-3.0.3 tar file not on Sources page
Checking CRAN today, I see that on the Sources page http://cran.r-project.org/sources.html that R-3.0.2.tar.gz is still there. R-3.0.3.tar.gz is available from the Older releases are available >>here<<. hyperlink to http://cran.r-project.org/src/base/ Is this the right place to report this, for an update to the Sources page? Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Two R editiosn in Unix cluster systems
> -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] > On Behalf Of Paul Johnson > Sent: October-15-13 1:15 PM > To: R Devel List > Cc: Discussion of Rocks Clusters > Subject: [Rd] Two R editiosn in Unix cluster systems > > Dear R Devel > > Some of our R users are still insisting we run R-2.15.3 because of > difficulties with a package called OpenMX. It can't cooperate with new R, > oh well. > > Other users need to run R-3.0.1. I'm looking for the most direct route to > install both, and allow users to choose at runtime. > > In the cluster, things run faster if I install RPMs to each node, rather > than putting R itself on the NFS share (but I could do that if you think > it's really better) > > In the past, I've used the SRPM packaging from EPEL repository to make a > few little path changes and build R RPM for our cluster nodes. Now I face > the problem of building 2 RPMS, one for R-2.15.3 and one for R-newest, and > somehow keeping them separate. > > If you were me, how would you approach this? Our bioinformatics group needs multiple versions of R and other software for a variety of compatibility issues. We thus gave up on trying to keep multiple versions of R and related pipeline software on all nodes of our cluster. We set up a mount point on each cluster node pointing to a directory structure on the head node (/share/apps). We compile and link all necessary materials in that directory structure, so that no executables or shared objects from /usr or other local drive locations need be accessed. All code is in e.g. /share/apps/R/R-x.yy.z so all the nodes can see all the versions. We have shared libraries in e.g. /share/apps/usr/lib All pipeline scripts use full paths to R and other executables, and since R is self-contained when appropriately compiled as you note below, there's no path clashing. (We also abandoned NFS for lustre so we don't have the speed issue you might face with such an arrangement. But generally code just needs to be read once and is then kept in memory by current OSs, so you might not notice much of a speed hit as far as getting the executable into memory.) Maintaining one set of code accessible to all nodes has made things much simpler than trying to set up all the rpms on the head node so that all compute nodes get it all installed locally. Some attention to detail is important at compile time, to ensure that all bits that go into the compilation really do come from /share/apps but that's about it. This has been easier to accomplish than maintaining a library of rpms on the head node and managing the distribution scripts to push out to the compute nodes. Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre > Here's my guess > > First, The RPM packages need unique names, of course. > > Second, leave the RPM packaging for R-newest exactly the same as it always > was. R is in the path, the R script and references among all the bits will > be fine, no need to fight. It will find what it needs in /usr/lib64/R or > whatnot. > > For the legacy R, I'm considering 2 ideas. I could install R with the same > prefix, /usr, but very careful so the R bits are installed into separate > places. I just made a fresh build of R and on RedHat 6, it appears to me R > installs these directories: > bin > libdir > share. > > So what if the configure line has the magic bindir=/usr/bin-R-2.15.3 > libdir = /usr/lib64/R-2.15.3, and whatnot. If I were doing Debian > packaging, I suppose I'd be obligated (by the file system standard) to do > that kind of thing. But it looks like a headache. > > The easy road is to set the prefix at some out of the way place, like > /opt/R-2.15.3, and then use a post-install script to link > /opt/R-2/15.3/bin/R to /usr/bin/R-2.15.3. When I tried that, it surprised > me because R did not complain about lack access to devel headers. It > configures and builds fine. > > R is now configured for x86_64-unknown-linux-gnu > > Source directory: . > Installation directory:/tmp/R > > C compiler:gcc -std=gnu99 -g -O2 > Fortran 77 compiler: gfortran -g -O2 > > C++ compiler: g++ -g -O2 > Fortran 90/95 compiler:gfortran -g -O2 > Obj-C compiler:gcc -g -O2 -fobjc-exceptions > > Interfaces supported: X11, tcltk > External libraries:readline, ICU, lzma > Additional capabilities: PNG, JPEG, TIFF, NLS, cairo > Options enabled: shared BLAS, R profiling, Java > > Recommended packages: yes > > Should I worry about any runtime complicatio
Re: [Rd] F statistic in add1.lm vs add1.glm
> stats:::add1.glm
function (object, scope, scale = 0, test = c("none", "Rao", "LRT",
"Chisq", "F"), x = NULL, k = 2, ...)
{
Fstat <- function(table, rdf) {
dev <- table$Deviance
df <- table$Df
diff <- pmax(0, (dev[1L] - dev)/df)
Fs <- (diff/df)/(dev/(rdf - df))
Is this where the double division is happening?
diff has df in the denominator, then Fs assignment sees
diff divided by df again. if df is 1, the double division
will go unnoticed.
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of William Dunlap [wdun...@tibco.com]
Sent: June 25, 2013 12:01 PM
To: r-devel@r-project.org
Subject: [Rd] F statistic in add1.lm vs add1.glm
Should the F statistic be the same when using add1() on models created by lm
and glm(family=gaussian)?
They are in the single-degree-of-freedom case but not in the
multiple-degree-of-freedom case.
MASS:addterm shows the same discrepancy. It looks like the deviance
(==residual sum of squares) gets
divided by the number of degrees of freedom for the term twice in add1.glm.
Using anova() on the output
of lm and glm(family=gaussian) gives the save F statistic as add1.lm gives.
> # factor(carb) consumes 5 degrees of freedom, am 1, compare their F values.
> fit <- lm(mpg ~ hp, data=mtcars) ; add1(fit, ~ hp + factor(carb) + am,
> test="F")
Single term additions
Model:
mpg ~ hp
Df Sum of SqRSSAIC F value Pr(>F)
447.67 88.427
factor(carb) 5103.54 344.13 90.009 1.5044 0.2241
am1202.24 245.44 71.194 23.8952 3.46e-05 ***
---
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
> fit <- glm(mpg ~ hp, data=mtcars) ; add1(fit, ~ hp + factor(carb) + am,
> test="F")
Single term additions
Model:
mpg ~ hp
Df DevianceAIC F value Pr(>F)
447.67 181.24
factor(carb) 5 344.13 182.82 0.3009 0.9077
am1 245.44 164.01 23.8952 3.46e-05 ***
---
Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
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] Depreciating partial matching
> -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] > On Behalf Of Andreas Leha > Sent: March-21-13 3:33 PM > To: r-de...@stat.math.ethz.ch > Subject: Re: [Rd] Depreciating partial matching > > Terry Therneau writes: > > > On 03/21/2013 10:00 AM, Simon Urbanek wrote: > >>>> I would think that the ability to hit the Tab key to trigger name > >>>> >> completion in your R GUI makes partial matching almost useless. > The > >>>> >> avantage of interactive completion in the GUI is that you > immediately > >>>> >> see the result of the partial matching. So you get the best of > both > >>>> >> worlds: no need to type long variable names in full, but no traps > when a > >>>> >> match is not what you would expect. > >>>> >> >> Doesn't this suit your use case? > >>> > Good point. This works well at the command line. However, not > >>> > when interacting between emacs and R in the way I do. For > >>> > reproducability I use and emacs file that is being corrected and > >>> > massaged with chunks submitted to R; at the end I have a clean > >>> > record of how the result was obtained. > >>> > > >> If this is really true (that ESS doesn't complete in R files) then > >> this seems more like a bug (or wish?) report for ESS - other editors > >> correctly support code completion in R documents - after all this is > >> a feature of R, so they don't need to re-invent the wheel. > >> > >> Cheers, > >> Simon > > If you are running the R process inside ESS then there is matching -- > > it is R. Doing this, keeping a log file, and then post-hoc cleaning > > up all the cruft from that file is one way to keep documentation. But > > since for my analyses the number of models/plots/etc that turn out to > > be detours or dead ends on the way to a solution is larger than the > > worthwhile part (typos alone are lots larger) I prefer to keep the > > file(s) as their own buffers and submit bits of them to an R process > > either by cut-paste to a separate window or ess-submit to an inferior > > process. Emacs can't do name completion in that case. Nor could it > > do so in an Sweave file, unless you were to keep a live R process in > > hand to pre-test chunks as you wrote them. (One could reasonably > > argue that when one gets the Sweave stage the names should be > > expanded.) > > Not true (any more?). > > , > | ESS[S] is the mode for editing S language files. This mode handles: > | > | [...] > | - completion of object names and file names. > ` > from > http://ess.r-project.org/Manual/ess.html#ESS_0028S_0029_002d_002dEditing- > files > > > ESS can do completion of functions, object names, and also > list/data.frame elements in *both* the inferior R buffer as well as in > the .R file. > > [...] Looking forward to that! But it is not working at present. The link above points to the development version ess-13 which I downloaded using svn export (I got version 13.03, running on a Mac with emacs 24.3). Completion of object names works in the inferior ESS buffer but not yet in an ESS buffer ( .R file). Steven McKinney > > - Andreas > > __ > 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 due to naive copying of list elements
Whereas > a <- list(c(1,2),c(3,4),c(5,6)) > b <<- a[2:3] > a[[2]][2] <- 9 > b [[1]] [1] 3 4 [[2]] [1] 5 6 > Examples such as this leave me in a cold sweat - where did I miss the documentation describing Radford's case? Can anyone point to the documentation that describes Radford's outcome? (It looks very lisp-like. Is it linked to R's origins in lisp?) I get the same outcome in R-2.11.1 so it is nothing new. I can only hope I have not set up such an effect in analysis scripts I've used to generate reproducible publication output. Steven McKinney From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of David Winsemius [dwinsem...@comcast.net] Sent: March 12, 2013 10:28 AM To: Radford Neal Cc: r-devel@r-project.org Subject: Re: [Rd] Bugs due to naive copying of list elements On Mar 12, 2013, at 3:59 AM, Radford Neal wrote: > Several bugs are present in R-2.15.3 and R-alpha due to > naive copying of list elements. > > The bug below is due to naive copying in subset.c (with > similar bugs for matrices and arrays): > > a<-list(c(1,2),c(3,4),c(5,6)) > b<-a[2:3] > a[[2]][2]<-9 > print(b[[1]][2]) This is an example of lazy evaluation, right? > > Naive copying in mapply.c leads to the following bug: > > X<-1+1 > f<-function(a,b) X > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > print(A) > X[1]<-99 > print(A) > Is this a bug in mapply()? or in print()? I thought 'print' should evaluate its argument and "force" the promise to be executed. Or does it just return the same promise as was passed to it? Compare: X<-1+1 f<-function(a,b) X A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) print(A); str(A) X[1]<-99 print(A) Could someone could comment on what 'force' actually does. I am unclear why force(A) in the code above in the pace of str(A) did not have the effect I expected, whereas str(b) or str(A) did have that effect. > a<-list(c(1,2),c(3,4),c(5,6)) > b<-a[2:3]; force(b) [[1]] [1] 3 4 [[2]] [1] 5 6 > a[[2]][2]<-9 > print(b[[1]][2]) [1] 9 #-- > X<-1+1 > f<-function(a,b) X > A<-mapply(f,c(1,2,3),c(4,5,6),SIMPLIFY=FALSE) > print(A); force(A) [[1]] [1] 2 [[2]] [1] 2 [[3]] [1] 2 [[1]] [1] 2 [[2]] [1] 2 [[3]] [1] 2 > X[1]<-99 > print(A) [[1]] [1] 99 [[2]] [1] 99 [[3]] [1] 99 > Similar bugs exist in eapply, rapply, and vapply. > -- David Winsemius Alameda, CA, USA __ 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] nobs() with glm(family="poisson")
> -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] > On Behalf Of Milan Bouchet-Valat > Sent: February-27-13 12:56 PM > To: peter dalgaard > Cc: r-devel > Subject: Re: [Rd] nobs() with glm(family="poisson") > > Thanks for the (critical, indeed) answer! > > Le mercredi 27 février 2013 à 20:48 +0100, peter dalgaard a écrit : > > On Feb 27, 2013, at 19:46 , Milan Bouchet-Valat wrote: > > > > > I cannot believes nobody cares about this -- or I'm completely wrong > and > > > in that case everybody should rush to put the shame on me... :-p > > > > Well, nobs() is the number of observations. If you have 5 Poisson > > distributed counts, you have 5 observations. > Well, say that to the statistical offices that spend millions to survey > thousands of people with correct (but complex) sampling designs, they'll > be happy to know that the collected data only provides an information > equivalent to 5 independent outcomes. ;-) Milan: It seems to me you are mixing up Binomial and Poisson situations, and not assessing independence appropriately. The above example discusses Bernoulli outcomes which are sometimes aggregated into Binomial "cases" depending on the study design. Now if the survey samples people in the same household or even neighbourhood, those Bernoulli outcomes will not be independent (hence clustered survey techniques) and summing the Binomial denominators would not be appropriate, for the survey analysis or for BIC calculations. The "n" in the BIC calculation should reflect independent observations. If you knock on the same door 1000 times and ask the person who they will vote for, you do not have 1000 independent observations, even though your Binomial denominator is 1000. The example you show from ?glm is a Poisson example showing 9 independent Poisson counts. If I count the number of cars passing through an intersection during non-overlapping one minute intervals (say 9 such intervals), then the number of observations I have is the number of non-overlapping one minute interval car count totals (e.g. the nine counts c(18, 17, 15, 20, 10, 20, 25, 13, 12)), not the number of cars I saw in total. A piece of software that adds things up can not know the context from which the numbers were derived, so you have to figure out the level of independence appropriate to your study design and work out the BIC count accordingly. Raftery alludes to this in a preceding section: "When the data have been collected using a complex survey design with resulting weights, it is not yet clear what n should be, and this issue awaits further study. However, it seems reasonable that if the model is based on an assumption of simple random sampling but the sampling design is less efficient, then n should be reduced to reflect the efficiency of the sampling design relative to simple random sampling." Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre > > > If the number of observations is not the right thing to use in some > > context, use the right thing instead. Changing the definition of > > nobs() surely leads to madness. > It is common usage in the literature using log-linear models to report > the sum of counts as the number of observations. I think this indeed > makes sense, but I'm not particularly attached to the choice of words -- > let's call it as you please. > > The root issue is that nobs() was precisely introduced to be the basis > for the BIC() function, as ?nobs states explicitly: > > Extract the number of ‘observations’ from a model fit. This is > > principally intended to be used in computing BIC (see ‘AIC’) > > So it's OK to say that the number of observations is the number of cells > (even if I think this is not very user-friendly), but then the > documentation is misleading, and the BIC() function returns incorrect > values for the very first example provided in ?glm. > > > (I suppose that the fact that n is so obviously the wrong thing for > > one particularly well-digested family of distribution functions could > > be taken to indicate a generic weakness with the BIC.) > I'm sure we can agree on the fact that BIC has its weaknesses (and I'm > not the best person able to judge), but the point at stake is IMHO not > one of them. After all, usual statistics for the Poisson family, such as > deviance or residuals, are based on the sum of counts, not on the number > of cells, and nobody objects. > > The fact that the AIC is perfectly integrated into S/R and BIC seems to > be merely an historical detail to me. Computing the AIC itself requires > glm.fit() to add twice t
Re: [Rd] seq.Date bug?
> -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] > On Behalf Of Jeffrey Ryan > Sent: January-31-12 12:47 PM > To: Dirk Eddelbuettel > Cc: R-devel org > Subject: Re: [Rd] seq.Date bug? > > format(ISOdate(2012,1:12,1),"%b-%Y") > > [1] "Jan-2012" "Feb-2012" "Mar-2012" "Apr-2012" "May-2012" "Jun-2012" > [7] "Jul-2012" "Aug-2012" "Sep-2012" "Oct-2012" "Nov-2012" "Dec-2012" > > First of the month is just as clean, and AFAIR they all have a first ;-) >From which you can get the last... > format(ISOdate(2012,1:12,1)-86400,"%d-%b-%Y") [1] "31-Dec-2011" "31-Jan-2012" "29-Feb-2012" "31-Mar-2012" "30-Apr-2012" "31-May-2012" [7] "30-Jun-2012" "31-Jul-2012" "31-Aug-2012" "30-Sep-2012" "31-Oct-2012" "30-Nov-2012" ... though leap seconds might require a bit more tweaking... Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre > > Jeff > > On Tue, Jan 31, 2012 at 2:37 PM, Dirk Eddelbuettel wrote: > > > > On 31 January 2012 at 15:17, Duncan Murdoch wrote: > > | On 12-01-31 2:56 PM, Dirk Eddelbuettel wrote: > > | > > > | > R> seq(as.Date(Sys.Date()), by="-1 months", length=6) > > | > [1] "2012-01-31" "2011-12-31" "2011-12-01" "2011-10-31" "2011-10-01" > "2011-08-31" > > | > R> > > | > > > | > Notice how October appears twice. > > | > > | > > > | > Now, date arithmetic is gruesome but the documentation for seq.Date > et al > > | > does not hint it wouldn't honour the by= argument. So a bug, or > merely a > > | > somewhat less than desirable features. > > | > > | It is giving you Jan 31, Dec 31, Nov 31, Oct 31, Sep 31, Aug 31 -- > > | except some of those months don't have 31 days, so it is converting > > | those dates to ones that really exist. (This is documented in > ?seq.POSIXt.) > > | > > | Isn't this what you asked for? > > > > No as I was feeding this into format(..., "%b-%y") to create 'pretty' > names, > > and the double entries screw that. > > > > Morale: pick a mid-month date, and shift that. > > > > Dirk > > > > | Duncan Murdoch > > | > > | > > | > > > | > (And yes, I think I know that Hadley's lubridate has code for this > too, but > > | > so may my RcppBDT which is sitting on top of Boost::DateTime code > ...) > > | > > > | > Dirk > > | > > > | > > > > -- > > "Outside of a dog, a book is a man's best friend. Inside of a dog, it is > too > > dark to read." -- Groucho Marx > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Jeffrey Ryan > jeffrey.r...@lemnica.com > > www.lemnica.com > www.esotericR.com > > R/Finance 2012: Applied Finance with R > www.RinFinance.com > > See you in Chicago > > __ > 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] png cairo device problems on Mac 10.6.8
> -Original Message-
> From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> Sent: January-18-12 3:10 PM
> To: Steven McKinney
> Cc: R-devel@r-project.org
> Subject: Re: [Rd] png cairo device problems on Mac 10.6.8
>
>
> On Jan 18, 2012, at 5:22 PM, Steven McKinney wrote:
>
> >
> > Hi all,
> >
> > I have been having problems generating png files on a Mac running OS X
> 10.6.8.
> >
> > Here's a simple example
> >
> >> png("foo.png", type = "cairo"); plot(1:10); dev.off();
> > null device
> > 1
> > libpng warning: Application built with libpng-1.2.26 but running with
> 1.5.2
> >
> > The resultant file is of size 0 Kb.
> >
> > Is this the proper place to report this issue? Or should this
> > be reported to r-sig-mac?
> >
>
> yes
>
>
> > If I run
> >
> >> png("foo.png"); plot(1:10); dev.off();
> > null device
> > 1
> >
> > I get a 16 Kb file with the appropriate plot. (Odd, since the default
> type is "cairo".)
> >
>
> No, the default is "quartz" unless you change it in your options.
D'oh! I should have verified by reading the source. Apologies for
the misinformation. The fact that "cairo" appears first in the
type argument list does not make it the default.
>
> On a similar note type="cairo-png" works as well.
Yes, type="cairo-png" yields a successful file.
The png() function shows a call of
invisible(.External(devCairo, filename, 2L, g$width, ...
for type="cairo" and a call of
invisible(.External(devCairo, filename, 5L, g$width, ...
with type="cairo-png" so the third argument (2 or 5)
appears to be the only difference. I have not dug into
the devCairo code to see how that arg is handled.
>
> The problem seems to be with R's configuration - for some mysterious reason
> it picks libpng12 flags even though cairo clearly includes libpng15 (and so
> does pkg-config). I'll need to dig a bit into that.
Thank you very much.
Cheers
Steve
>
> Cheers,
> Simon
>
>
> > Whenever I see the libpng warning, I end up with a 0 Kb file.
> >
> > Details of R session below.
> >
> >
> > Regards
> >
> > Steve McKinney
> >
> >
> >
> > R version 2.14.1 Patched (2012-01-11 r58090)
> > Copyright (C) 2012 The R Foundation for Statistical Computing
> > ISBN 3-900051-07-0
> > Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> > Natural language support but running in an English locale
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> > [R.app GUI 1.44 (5997) x86_64-apple-darwin9.8.0]
> >
> > [History restored from /Users/stevenmckinney/.Rhistory]
> >
> >> png("foo.png"); plot(1:10); dev.off();
> > null device
> > 1
> >> png("foo.png", type = "cairo"); plot(1:10); dev.off();
> > null device
> > 1
> > libpng warning: Application built with libpng-1.2.26 but running with
> 1.5.2
> >> ?png
> > starting httpd help server ... done
> >> capabilities()
> > jpeg png tifftcltk X11 aqua http/ftp sockets
> libxml fifo
> >TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
> TRUE TRUE
> > clediticonv NLS profmemcairo
> >TRUE TRUE TRUE TRUE TRUE
> >> png("foo.png"); plot(1:10); dev.off();
> > null device
> > 1
> >> sessionInfo()
> > R version 2.14.1 Patched (2012-01-11 r58090)
> > Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
> >
> > locale:
> > [1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
> >
> > attached base packages:
> > [1] stats graphics grDevices utils datasets methods base
> >
> > loaded via a namespace (and not attached):
> > [1] tools_2.14.1
> >>
> >
> >
> > Steven McKinney, Ph.D.
> >
> > Statistician
> > Molecular Oncology and Breast Cancer Program
> > British Columbia Cancer Research Centre
> >
> > email: smckinney +at+ bccrc +dot+ ca
> >
> > tel: 604-675-8000 x7561
> >
> > BCCRC
> > Molecular Oncology
> > 675 West 10th Ave, Floor 4
> > Vancouver B.C.
> > V5Z 1L3
> > Canada
> >
> > __
> > 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] png cairo device problems on Mac 10.6.8
Hi all,
I have been having problems generating png files on a Mac running OS X 10.6.8.
Here's a simple example
> png("foo.png", type = "cairo"); plot(1:10); dev.off();
null device
1
libpng warning: Application built with libpng-1.2.26 but running with 1.5.2
The resultant file is of size 0 Kb.
Is this the proper place to report this issue? Or should this
be reported to r-sig-mac?
If I run
> png("foo.png"); plot(1:10); dev.off();
null device
1
I get a 16 Kb file with the appropriate plot. (Odd, since the default type is
"cairo".)
Whenever I see the libpng warning, I end up with a 0 Kb file.
Details of R session below.
Regards
Steve McKinney
R version 2.14.1 Patched (2012-01-11 r58090)
Copyright (C) 2012 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
[R.app GUI 1.44 (5997) x86_64-apple-darwin9.8.0]
[History restored from /Users/stevenmckinney/.Rhistory]
> png("foo.png"); plot(1:10); dev.off();
null device
1
> png("foo.png", type = "cairo"); plot(1:10); dev.off();
null device
1
libpng warning: Application built with libpng-1.2.26 but running with 1.5.2
> ?png
starting httpd help server ... done
> capabilities()
jpeg png tifftcltk X11 aqua http/ftp sockets
libxml fifo
TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
TRUE TRUE
clediticonv NLS profmemcairo
TRUE TRUE TRUE TRUE TRUE
> png("foo.png"); plot(1:10); dev.off();
null device
1
> sessionInfo()
R version 2.14.1 Patched (2012-01-11 r58090)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.14.1
>
Steven McKinney, Ph.D.
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: smckinney +at+ bccrc +dot+ ca
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in documentation of "merge"
> -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] > On Behalf Of Kasper Daniel Hansen > Sent: November-04-11 5:26 AM > To: peter dalgaard > Cc: r-devel@r-project.org > Subject: Re: [Rd] Error in documentation of "merge" > > On Fri, Nov 4, 2011 at 8:20 AM, peter dalgaard wrote: > > > > On Nov 4, 2011, at 13:11 , Rainer M Krug wrote: > > > >> Hi > >> > >> there seems to be an error in the documentation of the "merge" function: > >> > >> Arguments: > >> > >> x, y: data frames, or objects to be coerced to one. > >> > >> by, by.x, by.y: specifications of the common columns. See ŒDetails‚. > >> > >> all: logical; Œall = L‚ is shorthand for Œall.x = L‚ and Œall.y = > >> L‚. > >> > >> > >> The "L" should be a T or a TRUE. > > > > > > I think it's on purpose: L indicates a logical value, TRUE _or_ FALSE. > > I agree with Peter here. But it did make me pause the first time I > read it on the help page years ago and furthermore, I think this is at > least the second time where this particular formulation has been > questioned on R-devel. I am not an index of R help pages, but I > cannot recall seeing the 'L' as shorthand for logical. I suggest > changing the formulation since it seems that several people have been > confused, for example by writing out 'logical' instead of 'L'. Seconded, as L does have another use as well now in numeric constants > 1L [1] 1 Steven McKinney > > Kasper > > __ > 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] Testing window for R 2.13.0
> -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On > Behalf Of Prof Brian > Ripley > Sent: March-18-11 2:22 PM > To: R-devel@r-project.org > Subject: [Rd] Testing window for R 2.13.0 > > We are now starting testing R 2.13.0/alpha/beta/RC and testing and > feedback would be appreciated (whereas reports on problems immediately > after release will try our patience). Thank you for another release and all of your hard work. Hopefully your degree of impatience with reports immediately after release is inversely proportional to the number of reports before release. Given some good pre-release feedback it would be a shame to discourage reports immediately after release :) I'll install and start testing now... Having worked for a commercial software company, I am continuously amazed at how quickly bugs are fixed, feature requests are implemented, and patched versions released by this open source group (this includes Bioconductor and many of the package maintainers). No commercial vendor that I know of can or will match this response. Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre > > Sources are available at > http://cran.r-project.org/src/base-prerelease/ > Windows binaries at > http://cran.r-project.org/bin/windows/base/rtest.html > and Mac binaries at http://r.research.att.com/, specifically > http://r.research.att.com/R-2.13-branch-leopard.pkg > (and it is best to use the CRAN master rather than mirrors which will > lag behind). > > Please report (success as well as failure except on the most common > platforms) here, r-wind...@r-project.org or r-sig-...@r-project.org. > We probably have good coverage of Debian/Fedora i686/x86_64 Linux, Mac > OS X, Windows, Solaris and x86_64 FreeBSD 8.2: reports on other > platforms would be particularly welcome. > > There have been a number of confused postings about 64-bit R on > Solaris: the R-admin manual in this version contains detailed > instructions on what works for us (Solaris Studio 12.2 and 12u1, and > gcc4 on Sparc) and what doesn't (gcc on amd64) and why. > > Package maintainers should review the results for their packages at > http://cran.r-project.org/web/checks/check_summary.html > and submit updates if needed as soon as possible and definitely well > before April 13. That page is in the process of migration to > R-prerel: for now the most useful columns are r-devel (Fedora), > r-devel (Windows, really R-prerel) and the Solaris x86 column. > > Brian Ripley (for the R-core team) > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
> Behalf Of Duncan Murdoch
> Sent: February-15-11 3:10 PM
> To: Kevin Wright
> Cc: R Devel List
> Subject: Re: [Rd] Request: Suggestions for "good teaching" packages, esp.
> with C code
>
> On 15/02/2011 5:22 PM, Kevin Wright wrote:
> > For those of you "familiar with R", here's a little quiz. What what's the
> > difference between:
> >
> >
> > f1<- function(){
> >a=5
> > }
>
> This returns 5, invisibly. It's also bad style, according to those of
> us who prefer <- to = for assignment.
For maximum clarity
f0 <- function() {
b <- 5
return( list( a = b ) )
}
> f0()
$a
[1] 5
Steven McKinney
>
> > f2<- function(){
> >return(a=5)
> > }
>
> This is a mistake: return() doesn't take named arguments. It is
> lenient and lets you get away with this error (treating it the same as
> return(5)), and returns the 5, visibly.
>
> Duncan Murdoch
>
> > f2()
> >
> >
> > Kevin Wright
> >
> >
> >
> >
> > On Tue, Feb 15, 2011 at 3:55 PM, Geoff Jentrywrote:
> >
> >> On Wed, 16 Feb 2011, David Scott wrote:
> >>
> >>> 4. We don't want gratuitous use of "return" at the end of functions.
> >>>> Why do people still do that?
> >>>>
> >>> Well I for one (and Jeff as well it seems) think it is good programming
> >>> practice. It makes explicit what is being returned eliminating the
> >>> possibility of mistakes and provides clarity for anyone reading the code.
> >>>
> >>
> >> You're unnecessarily adding the overhead of a function call by explicitly
> >> calling return().
> >>
> >> Sure it seems odd for someone coming from the C/C++/Java/etc world, but
> >> anyone familiar with R should find code that doesn't have an explicit
> >> return() call to be fully readable& clear.
> >>
> >> -J
> >>
> >>
> >> __
> >> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] use of depends, suggests, etc
If you add the other package to Suggests, what problems do you see? Adding the other package to Suggests seems most appropriate, your use case seems very similar to packages discussed in a vignette. Steven McKinney From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Prof Brian Ripley [rip...@stats.ox.ac.uk] Sent: January 27, 2011 2:12 PM To: Kevin R. Coombes Cc: r-devel@r-project.org Subject: Re: [Rd] use of depends, suggests, etc On Thu, 27 Jan 2011, Kevin R. Coombes wrote: > Hi, > > I'm putting together an R package. In explaining how it works (in the Rd > files), I want to refer to another package. The other package is not used > anywhere in the actual code nor in the examples. So, there is no reason to > include the other package in the Depends, Suggests, or Imports lines of the > DESCRIPTION file. People will be able to use my package without actually > installing the other package. > > However, "R CMD check" warns about "Missing link(s)" when it is checking the > cross references in the Rd files. > > What is the preferred way to make this warning go away? Follow the 'Writing R Extensions' manual. There is a 3-item bullet point in §1.1.1 following 'The general rules are' and your claims contradict the third point. > > Thanks in advance, >Kevin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Indexing request
Yes, odd that ?Constants doesn't work, given that there is a page labeled
Constants {base}.
On a happier note, these all work now on my Mac R version 2.11.1
> ?base
> ?stats
> ?utils
though Constants is not an entry in the index.
R help gurus - is it possible to have entries such as "Constants"
for such help pages that discuss multiple functions?
On further poking around I do see an index entry for "assignOps"
for page assignOps {base} so the answer is obviously "yes".
I guess it's now a matter of providing a patch or convincing
an R developer to do so in his copious spare time :)
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of David Winsemius [dwinsem...@comcast.net]
Sent: January 6, 2011 9:08 PM
To: r-de...@stat.math.ethz.ch
Subject: [Rd] Indexing request
I just tried ?Constants at the console and was disappointed that the
so-named base help page would not come up.
> ?Constants
No documentation for 'Constants' in specified packages and libraries:
you could try '??Constants'
Seems like there should have been a match. I was looking for the month
abbreviations, failing to hit the right name 4 times and then failing
3 more times on variations of what I remembered to be the name of that
page and finally ended up typing:
?letters
--
David Winsemius, MD
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] RMySQL package on 64bit R for Windows
I think this is a question for R-devel so I'm cross-posting there with apologies. I've just acquired a Windows 7 64-bit box and also will need RMySQL eventually. Is there any information about issues involved with compiling RMySQL for Windows 64-bit? Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre > -Original Message- > From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On > Behalf Of abeSRT > Sent: July-16-10 1:00 PM > To: r-h...@r-project.org > Subject: Re: [R] RMySQL package on 64bit R for Windows > > > Did you ever find a solution for this? > -- > View this message in context: > http://r.789695.n4.nabble.com/RMySQL-package-on-64bit-R-for-Windows- > tp2248726p2291892.html > Sent from the R help mailing list archive at Nabble.com. > > __ > r-h...@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
> -Original Message-
> From: Benilton Carvalho [mailto:bcarv...@jhsph.edu]
> Sent: Thursday, November 19, 2009 6:59 PM
> To: Steven McKinney
> Cc: 'm...@celos.net'; 'r-de...@stat.math.ethz.ch'
> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
>
> Steve,
>
> I'm no expert on this, but my understanding is that the choice was to
> stick to the definition.
>
> The help file for length() [1] says:
>
> "For vectors (including lists) and factors the length is the number of
> elements."
>
> The help file for POSIXlt [2] (for example) says:
>
> "Class '"POSIXlt"' is a named list of vectors representing (...)"
>
> and then lists the 9 elements (sec / min / hour / mday / mon / year /
> wday / yday / isdst).
>
> So, by [1] length of POSIXlt objects is 9, because it "is a named list
> of vectors representing (...)".
Thanks, a most sensible description.
After how many bug reports does it qualify for addition to the FAQ?!
Steve McKinney
>
> b
>
> On Nov 20, 2009, at 12:19 AM, Steven McKinney wrote:
>
> >
> > I've checked the archives, and this problem crops up every
> > few months going back for years.
> >
> > What I was not able to find was an explanation of why a
> > function such as
> > length.POSIXlt <- function(x) { length(x$sec) }
> > is a Bad Idea, or what it would break. listserv threads
> > seem to end without presenting an answer. R News 2001
> > Vol 1/2 discusses that "lots of methods are needed..."
> > (page 11) but I haven't found discussion of why a length
> > method isn't feasible.
> >
> > Can anyone clarify this, or point me at the right
> > archive or documentation source that discusses why
> > objects of class POSIXlt always need to return a
> > length of 9?
> >
> > Thanks
> > Steve McKinney
> >
> >
> >> -Original Message-
> >> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> >> project.org] On Behalf Of Benilton Carvalho
> >> Sent: Thursday, November 19, 2009 4:29 PM
> >> To: m...@celos.net
> >> Cc: r-de...@stat.math.ethz.ch
> >> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
> >>
> >> Check the documentation and the archives. Not a bug. b
> >>
> >> On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
> >>
> >>> Arrays of POSIXlt dates always return a length of 9. This
> >>> is correct (they're really lists of vectors of seconds,
> >>> hours, and so forth), but other methods disguise them as
> >>> flat vectors, giving superficially surprising behaviour:
> >>>
> >>> strings <- paste('2009-1-', 1:31, sep='')
> >>> dates <- strptime(strings, format="%Y-%m-%d")
> >>>
> >>> print(dates)
> >>> # [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
> >>> "2009-01-05"
> >>> # [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
> >>> "2009-01-10"
> >>> # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
> >>> "2009-01-15"
> >>> # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
> >>> "2009-01-20"
> >>> # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
> >>> "2009-01-25"
> >>> # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
> >>> "2009-01-30"
> >>> # [31] "2009-01-31"
> >>>
> >>> print(length(dates))
> >>> # [1] 9
> >>>
> >>> str(dates)
> >>> # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
> >>> "2009-01-04" ...
> >>>
> >>> print(dates[20])
> >>> # [1] "2009-01-20"
> >>>
> >>> print(length(dates[20]))
> >>> # [1] 9
> >>>
> >>> I've since realised that POSIXct makes date vectors easier,
> >>> but could we also have something like:
> >>>
> >>> length.POSIXlt <- function(x) { length(x$sec) }
> >>>
> >>> in datetime.R, to avoid breaking functions (like the
> >>> str.POSIXt method) which use length() in this way?
> >>>
> >>> Thanks,
> >>> Mark <><
> >>>
> >>> --
> >>>
> >>> Version:
> >>> platform = i686-pc-linux-gnu
> >>> arch = i686
> >>> os = linux-gnu
> >>> system = i686, linux-gnu
> >>> status =
> >>> major = 2
> >>> minor = 10.0
> >>> year = 2009
> >>> month = 10
> >>> day = 26
> >>> svn rev = 50208
> >>> language = R
> >>> version.string = R version 2.10.0 (2009-10-26)
> >>>
> >>> Locale:
> >>> C
> >>>
> >>> Search Path:
> >>> .GlobalEnv, package:stats, package:graphics, package:grDevices,
> >>> package:utils, package:datasets, package:methods, Autoloads,
> >>> package:base
> >>>
> >>> __
> >>> 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] Surprising length() of POSIXlt vector (PR#14073)
I've checked the archives, and this problem crops up every
few months going back for years.
What I was not able to find was an explanation of why a
function such as
length.POSIXlt <- function(x) { length(x$sec) }
is a Bad Idea, or what it would break. listserv threads
seem to end without presenting an answer. R News 2001
Vol 1/2 discusses that "lots of methods are needed..."
(page 11) but I haven't found discussion of why a length
method isn't feasible.
Can anyone clarify this, or point me at the right
archive or documentation source that discusses why
objects of class POSIXlt always need to return a
length of 9?
Thanks
Steve McKinney
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Benilton Carvalho
> Sent: Thursday, November 19, 2009 4:29 PM
> To: m...@celos.net
> Cc: r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
>
> Check the documentation and the archives. Not a bug. b
>
> On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
>
> > Arrays of POSIXlt dates always return a length of 9. This
> > is correct (they're really lists of vectors of seconds,
> > hours, and so forth), but other methods disguise them as
> > flat vectors, giving superficially surprising behaviour:
> >
> > strings <- paste('2009-1-', 1:31, sep='')
> > dates <- strptime(strings, format="%Y-%m-%d")
> >
> > print(dates)
> > # [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
> > "2009-01-05"
> > # [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
> > "2009-01-10"
> > # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
> > "2009-01-15"
> > # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
> > "2009-01-20"
> > # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
> > "2009-01-25"
> > # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
> > "2009-01-30"
> > # [31] "2009-01-31"
> >
> > print(length(dates))
> > # [1] 9
> >
> > str(dates)
> > # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
> > "2009-01-04" ...
> >
> > print(dates[20])
> > # [1] "2009-01-20"
> >
> > print(length(dates[20]))
> > # [1] 9
> >
> > I've since realised that POSIXct makes date vectors easier,
> > but could we also have something like:
> >
> > length.POSIXlt <- function(x) { length(x$sec) }
> >
> > in datetime.R, to avoid breaking functions (like the
> > str.POSIXt method) which use length() in this way?
> >
> > Thanks,
> > Mark <><
> >
> > --
> >
> > Version:
> > platform = i686-pc-linux-gnu
> > arch = i686
> > os = linux-gnu
> > system = i686, linux-gnu
> > status =
> > major = 2
> > minor = 10.0
> > year = 2009
> > month = 10
> > day = 26
> > svn rev = 50208
> > language = R
> > version.string = R version 2.10.0 (2009-10-26)
> >
> > Locale:
> > C
> >
> > Search Path:
> > .GlobalEnv, package:stats, package:graphics, package:grDevices,
> > package:utils, package:datasets, package:methods, Autoloads,
> > package:base
> >
> > __
> > 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] R Usage Statistics
Hi Kevin, What a surprising comment from a reviewer for BMC Bioinformatics. I just did a PubMed search for "limma" and "aroma.affymetrix", just two methods for which I use R software regularly. "limma" yields 28 hits, several of which are published in BMC Bioinformatics. Bengtsson's aroma.affymetrix paper "Estimation and assessment of raw copy numbers at the single locus level." is already cited by 6 others. It almost seems too easy to work up lists of usage of R packages. Spotfire is an application built around S-Plus that has widespread use in the biopharmaceutical industry at a minimum. Vivek Ranadive's TIBCO company just purchased Insightful, the S-Plus company. (They bought Spotfire previously.) Mr. Ranadive does not spend money on environments that are not appropriate for deploying applications. You could easily cull a list of corporation names from the various R email listservs as well. Press back with the reviewer. Reviewers can learn new things and will respond to arguments with good evidence behind them. Good luck! Steven McKinney From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Kevin R. Coombes [krcoom...@mdacc.tmc.edu] Sent: November 19, 2009 10:47 AM To: r-devel@r-project.org Subject: [Rd] R Usage Statistics Hi, I got the following comment from the reviewer of a paper (describing an algorithm implemented in R) that I submitted to BMC Bioinformatics: "Finally, which useful for exploratory work and some prototyping, neither R nor S-Plus are appropriate environments for deploying user applications that would receive much use." I can certainly respond by pointing out that CRAN contains more than 2000 packages and Bioconductor contains more than 350. However, does anyone have statistics on how often R (and possibly some R packages) are downloaded, or on how many people actually use R? Thanks, Kevin __ 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] Bug in all.equal() or in the plm package
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Arne Henningsen
> Sent: Tuesday, November 10, 2009 2:24 AM
> To: Duncan Murdoch; r-devel@r-project.org; Yves Croissant;
> giovanni_mi...@generali.com; Achim Zeileis
> Subject: Re: [Rd] Bug in all.equal() or in the plm package
>
> On Mon, Nov 9, 2009 at 12:24 PM, Duncan Murdoch
> wrote:
> > Arne Henningsen wrote:
> >>
> >> I noticed that there is a (minor) bug either the command all.equal()
> >> or in the "plm" package. I demonstrate this using an example taken
> >> from the documentation of plm():
> >>
> >
> > I'm not sure this is a bug, but I'd call it at least a design flaw.
> The
> > problem is that the length.Formula method in the Formula package
> (which plm
> > depends on) returns a vector of length 2. Now there's nothing in R
> that
> > requires length() to return a scalar,
No, but outside of R, length is a one dimensional real number
except perhaps in some esoteric mathematics, so I'm puzzled
why length in R would be redefined to produce non-scalars.
> >but all.equal assumes it does,
> and I'd
> > guess there are lots of other places this assumption is made.
>
> Okay, let's call it "design flaw". Given that the "unusual" behaviour
> of length.Formula() causes this problem, I suggest that the
> length.Formula() method should be changed. Maybe to something like
>
> R> a <- as.Formula( y ~ x | z | w )
> # current behaviour:
> R> length(a)
> [1] 1 3
> # suggested behaviour:
> R> length(a)
> [1] 2
> R> length(a[[1]])
> [1] 1
> R> length(a[[2]])
> [1] 3
>
How about
# Total number of variables in model
R> length(a)
[1] 4
# Predictor variables (on the right hand side) pred(a) or rhs(a)
R> length(pred(a))
[1] 3
# Response variables (on the left hand side) resp(a) or lhs(a)
R> length(resp(a))
[1] 1
so all lengths of a formula's components can
be obtained as scalars.
R> length(a)
[1] 3
is what R 2.9.1 produced, and may often be what is expected
for the length of a formula, so the above could be
# Total number of variables in model
R> length(total(a))
[1] 4
# Predictor variables (on the right hand side) pred(a) or rhs(a)
R> length(a)
[1] 3
# Response variables (on the left hand side) resp(a) or lhs(a)
R> length(resp(a))
[1] 1
Steve McKinney
> This would be more consistent with the usual behaviour of length, e.g.
> R> b <- list( 1, 1:3 )
> R> length(b)
> [1] 2
> R> length(b[[1]])
> [1] 1
> R> length(b[[2]])
> [1] 3
>
> /Arne
>
>
> >> ==
> >> R> data("Produc", package="plm")
> >> R> zz <- plm(log(gsp)~log(pcap)+log(pc)+log(emp)+unemp,
> >> + data=Produc, index=c("state","year"))
> >> R> all.equal(zz,zz)
> >> [1] TRUE
> >> Warning message:
> >> In if (length(target) != length(current)) return(paste("target,
> >> current differ in having response: ", :
> >> the condition has length > 1 and only the first element will be
> used
> >>
> >>>
> >>> all.equal(zz$formula,zz$formula)
> >>>
> >>
> >> [1] TRUE
> >> Warning message:
> >> In if (length(target) != length(current)) return(paste("target,
> >> current differ in having response: ", :
> >> the condition has length > 1 and only the first element will be
> used
> >>
> >>>
> >>> class(zz$formula)
> >>>
> >>
> >> [1] "pFormula" "Formula" "formula"
> >> ==
> >>
> >> The last commands show that the warning message comes from comparing
> >> the elements "formula", which are of the class "pFormula"
> (inheriting
> >> from "Formula" and "formula"). It would be great if this issue could
> >> be fixed in the future.
> >>
> >> Thanks a lot,
> >> Arne
>
> --
> Arne Henningsen
> http://www.arne-henningsen.name
>
> __
> 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] Cannot Change Function (PR#14041)
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Stefan Evert
> Sent: Wednesday, November 04, 2009 4:40 AM
> To: michael_ka...@earthlink.net
> Cc: r-b...@r-project.org; r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Cannot Change Function (PR#14041)
>
> What makes you think this is a bug in R?
>
> > Whenever I try changing a function, it keeps coming up with the same
> > error
> > message.
> >
> > I have the function
> > CN_state_log_sum=function(Tot_log_sum){ #estimate copy number state
> > for the log
> [...]
> > }
> >
> > When I try to run it in the loop:
> > for (j in 1:length(BB_mean_ref)){ # find copy number states (0 for
> > homozygous
> > deletion, 1 for hemizygous deletion, 2 for neutral, 3 for single
> > amplification,
> > 4 for multiple amplification)
> > state_log_sum[j]=CN_state_log_sum(Tot_log_sum[j])
> > state_sum_log[j]=CN_state_sum_log(Tot_sum_log[j])
> > }
> > I get the error message:
> > Error in Im(Tot_sum_log) != 0 || Re(Tot_sum_log) <- 2 :
> > could not find function "||<-"
>
> The error message indicates that the problem happens in the function
> CN_state_sum_log() rather than CN_state_log_sum(), so it's hardly
> surprising that changing the latter doesn't have any effect.
>
> My guess: you've go a condition (Re(Tot_sum_log)<-2), which is
> mistaken for the assignment operator "<-" by the R parser. Adding some
> whitespace (Re(Tot_sum_log) < -2) should help both R and human readers
> to make sense of it.
Adding parentheses around the negative number is the only way to keep
such an expression robustly safe given the various whitespace alterations
that happen as such text passes through different parsers, editors,
mailers, proportional pitch font displays (which can fool human readers) ...
( ( Im(Tot_sum_log) != 0 ) || ( Re(Tot_sum_log) < (-2) ) )
Best
Steven McKinney
>
> Best,
> Stefan
>
> __
> 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] loadings function (PR#13886)
Hi Mike, Please don't file bug reports without first posing such questions on R-help or R-devel first, asking if such behaviour really is a bug. (This generates extra work for the volunteers who maintain R). In this case, it's your misunderstanding of the information about three different functions on the "loadings" help page. The loadings() function is shown with one argument "x" only. The other parameters described are for the print methods also discussed on the loadings() help page. Looking at the factanal example: > # A little demonstration, v2 is just v1 with noise, > # and same for v4 vs. v3 and v6 vs. v5 > # Last four cases are there to add noise > # and introduce a positive manifold (g factor) > v1 <- c(1,1,1,1,1,1,1,1,1,1,3,3,3,3,3,4,5,6) > v2 <- c(1,2,1,1,1,1,2,1,2,1,3,4,3,3,3,4,6,5) > v3 <- c(3,3,3,3,3,1,1,1,1,1,1,1,1,1,1,5,4,6) > v4 <- c(3,3,4,3,3,1,1,2,1,1,1,1,2,1,1,5,6,4) > v5 <- c(1,1,1,1,1,3,3,3,3,3,1,1,1,1,1,6,4,5) > v6 <- c(1,1,1,2,1,3,3,3,4,3,1,1,1,2,1,6,5,4) > m1 <- cbind(v1,v2,v3,v4,v5,v6) > > > fa <- factanal(m1, factors=3) # varimax is the default > fa Call: factanal(x = m1, factors = 3) Uniquenesses: v1v2v3v4v5v6 0.005 0.101 0.005 0.224 0.084 0.005 Loadings: Factor1 Factor2 Factor3 v1 0.944 0.182 0.267 v2 0.905 0.235 0.159 v3 0.236 0.210 0.946 v4 0.180 0.242 0.828 v5 0.242 0.881 0.286 v6 0.193 0.959 0.196 Factor1 Factor2 Factor3 SS loadings 1.893 1.886 1.797 Proportion Var 0.316 0.314 0.300 Cumulative Var 0.316 0.630 0.929 The degrees of freedom for the model is 0 and the fit was 0.4755 ### Now extract just the loadings > loadings(fa) Loadings: Factor1 Factor2 Factor3 v1 0.944 0.182 0.267 v2 0.905 0.235 0.159 v3 0.236 0.210 0.946 v4 0.180 0.242 0.828 v5 0.242 0.881 0.286 v6 0.193 0.959 0.196 Factor1 Factor2 Factor3 SS loadings 1.893 1.886 1.797 Proportion Var 0.316 0.314 0.300 Cumulative Var 0.316 0.630 0.929 ### Now attempt > loadings(fa, digits = 5) Error in loadings(fa, digits = 5) : unused argument(s) (digits = 5) ### loadings() takes only one argument. ### The digits and other arguments are for the print methods, e.g. > print(fa, digits = 5) Call: factanal(x = m1, factors = 3) Uniquenesses: v1 v2 v3 v4 v5 v6 0.00500 0.10090 0.00500 0.22405 0.08429 0.00500 Loadings: Factor1 Factor2 Factor3 v1 0.94384 0.18193 0.26661 v2 0.90472 0.23484 0.15948 v3 0.23564 0.20960 0.94634 v4 0.17998 0.24225 0.82757 v5 0.24211 0.88064 0.28560 v6 0.19277 0.95884 0.19621 Factor1 Factor2 Factor3 SS loadings1.89304 1.88576 1.79702 Proportion Var 0.31551 0.31429 0.29950 Cumulative Var 0.31551 0.62980 0.92930 The degrees of freedom for the model is 0 and the fit was 0.4755 > print(loadings(fa), digits = 5) Loadings: Factor1 Factor2 Factor3 v1 0.94384 0.18193 0.26661 v2 0.90472 0.23484 0.15948 v3 0.23564 0.20960 0.94634 v4 0.17998 0.24225 0.82757 v5 0.24211 0.88064 0.28560 v6 0.19277 0.95884 0.19621 Factor1 Factor2 Factor3 SS loadings1.89304 1.88576 1.79702 Proportion Var 0.31551 0.31429 0.29950 Cumulative Var 0.31551 0.62980 0.92930 > Best Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre email: smckinney +at+ bccrc +dot+ ca tel: 604-675-8000 x7561 BCCRC Molecular Oncology 675 West 10th Ave, Floor 4 Vancouver B.C. V5Z 1L3 Canada From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of mikedulr...@gmail.com [mikedulr...@gmail.com] Sent: August 11, 2009 9:15 AM To: r-de...@stat.math.ethz.ch Cc: r-b...@r-project.org Subject: [Rd] loadings function (PR#13886) Full_Name: Mike Ulrich Version: 2.9 OS: Mac OSX Submission from: (NULL) (69.169.178.34) The help documentation for loadings() lists more then one parameter. The function call only expects one parameter. The digits, cutoff, and sort parameters are not used in the function. ## S3 method for class 'loadings': print(x, digits = 3, cutoff = 0.1, sort = FALSE, ...) ## S3 method for class 'factanal': print(x, digits = 3, ...) > loadings function (x) x$loadings __ 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] Wishlist: Navigate to "Index" page of help when no topic (PR#13872)
Thanks Romain, I find index?survival more intuitive than my proposed ?survival:: Steven McKinney From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Romain Francois [romain.franc...@dbmail.com] Sent: August 4, 2009 11:24 PM To: murd...@stats.uwo.ca Cc: r-de...@stat.math.ethz.ch Subject: Re: [Rd] Wishlist: Navigate to "Index" page of help when no topic (PR#13872) Hello, I'm jumping a bit late on this, but what about something like: index?survival or more generally foo?bar with the ability for the user/package to define what the combination "foo"/"bar" means. At the moment, the way "package?survival" is handled is to : - create the string "package-survival" - call help with it Romain On 08/05/2009 02:10 AM, murd...@stats.uwo.ca wrote: > On 04/08/2009 7:33 PM, Steven McKinney wrote: >>> -Original Message- >>> From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] >>> Sent: Tuesday, August 04, 2009 8:03 AM >>> To: Steven McKinney >>> Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org >>> Subject: Re: [Rd] Wishlist: Navigate to "Index" page of help when no >>> topic specified (PR#13860) >>> >>> On 7/28/2009 6:30 PM, smckin...@bccrc.ca wrote: >>>> Hi all, >>>> >>>> When I install a new package, and don't yet know any function names, >>>> I have to play the "poor man's game" to get to the standard >>>> help system "Index" page for the package: >>> You could complain to the package author or maintainer, who should have >>> created a help alias with the package name so that ?survival would give >>> you something useful. But I would guess R 2.10.x or 2.11.x will do >>> that >>> automatically. >>> >>> Duncan Murdoch >> Unfortunately it happens frequently - hopefully I >> don't have to complain so much - I'd rather figure >> out code to get to the index page! >> >> When you say "I would guess R 2.10.x or 2.11.x will do >> that automatically" do you mean >> ?survival:: >> or some similar incantation >> will take me to the Index or 00Index page? > > I would guess package?survival will take you to a help page that is > similar to what you get now in the flat display from > library(help=survival). Ideally it will have a link on it to the index > page. It is possible that ?survival will work too; that may be more > controversial, because for many packages (e.g. boot) an alias like that > is already defined, pointing to something other than the package main page. > >> Do I need to propose code or is it already >> known how to do this within the R core group? > > I doubt if code to do that would be accepted (since it will be redundant > once the above changes are in place), but posting it to r-devel might > help people in the meantime. You should look at the tools package, > which has a number of functions that are used by R for constructing the > help pages; there's probably something there that will let you construct > a link to the index fairly easily. > > Duncan Murdoch > >> Best >> Steve McKinney >> >> >>>> Poor Man's Game -=20 >>>>Load new package;=20 >>>>issue search() command; >>>>find position (say N) of loaded package;=20 >>>>issue objects(pos =3D N) command; >>>>get name of a random function (san newFunction);=20 >>>>issue ?newFunction command; >>>>scroll to bottom of page;=20 >>>>click on the "Index" hyperlink >>>> >>>> There are other variations, but they all involve this=20 >>>> long march to the Index page. >>>> >>>> >>>> What I'd like to be able to do is enter the command >>>> >>>>> help(package =3D "survival") >>>> or >>>> >>>>> ?survival:: >>>> and get the usual hyperlinked help page displayed (the "00Index" >>> page) >>>> instead of the static "text only" display or an error message >>>> >>>> (for example, on Windows, this equates to invoking >>>> "C:/PROGRA~1/R/R-29~1.1/library/survival/chm/00Index" >>>> on Apple Mac, >>>> >>> "/Library/Frameworks/R.framework/Resources/library/survival/html/00Inde >>> x.ht= >>>> ml" >>>> etc.) >>>> >>>> >>
Re: [Rd] Wishlist: Navigate to "Index" page of help when no topic specified (PR#13860)
> -Original Message- > From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] > Sent: Tuesday, August 04, 2009 5:06 PM > To: Steven McKinney > Cc: 'r-de...@stat.math.ethz.ch'; 'r-b...@r-project.org' > Subject: Re: [Rd] Wishlist: Navigate to "Index" page of help when no > topic specified (PR#13860) > > On 04/08/2009 7:33 PM, Steven McKinney wrote: > >> -Original Message- > >> From: Duncan Murdoch [mailto:murd...@stats.uwo.ca] > >> Sent: Tuesday, August 04, 2009 8:03 AM > >> To: Steven McKinney > >> Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org > >> Subject: Re: [Rd] Wishlist: Navigate to "Index" page of help when no > >> topic specified (PR#13860) > >> > >> On 7/28/2009 6:30 PM, smckin...@bccrc.ca wrote: > >>> Hi all, > >>> > >>> When I install a new package, and don't yet know any function > names, > >>> I have to play the "poor man's game" to get to the standard > >>> help system "Index" page for the package: > >> You could complain to the package author or maintainer, who should > have > >> created a help alias with the package name so that ?survival would > give > >> you something useful. But I would guess R 2.10.x or 2.11.x will do > >> that > >> automatically. > >> > >> Duncan Murdoch > > > > Unfortunately it happens frequently - hopefully I > > don't have to complain so much - I'd rather figure > > out code to get to the index page! > > > > When you say "I would guess R 2.10.x or 2.11.x will do > > that automatically" do you mean > > ?survival:: > > or some similar incantation > > will take me to the Index or 00Index page? > > I would guess package?survival will take you to a help page that is > similar to what you get now in the flat display from > library(help=survival). Ideally it will have a link on it to the index > page. It is possible that ?survival will work too; that may be more > controversial, because for many packages (e.g. boot) an alias like that > is already defined, pointing to something other than the package main > page. Yes, package?survival and help(package = survival) and ?survival all are currently in use which is why I propose ?survival:: with no topic after the "::" as an incantation to go to the 00Index page. > > > Do I need to propose code or is it already > > known how to do this within the R core group? > > I doubt if code to do that would be accepted (since it will be > redundant > once the above changes are in place), but posting it to r-devel might > help people in the meantime. You should look at the tools package, > which has a number of functions that are used by R for constructing the > help pages; there's probably something there that will let you > construct > a link to the index fairly easily. Thanks for the information. I'll review package tools and work out some demonstrative code. > > Duncan Murdoch > > > Best > > Steve McKinney > > > > > >>> Poor Man's Game -=20 > >>> Load new package;=20 > >>> issue search() command; > >>> find position (say N) of loaded package;=20 > >>> issue objects(pos =3D N) command; > >>> get name of a random function (san newFunction);=20 > >>> issue ?newFunction command; > >>> scroll to bottom of page;=20 > >>> click on the "Index" hyperlink > >>> > >>> There are other variations, but they all involve this=20 > >>> long march to the Index page. > >>> > >>> > >>> What I'd like to be able to do is enter the command > >>> > >>>> help(package =3D "survival") > >>> or > >>> > >>>> ?survival:: > >>> and get the usual hyperlinked help page displayed (the "00Index" > >> page) > >>> instead of the static "text only" display or an error message > >>> > >>> (for example, on Windows, this equates to invoking > >>> "C:/PROGRA~1/R/R-29~1.1/library/survival/chm/00Index" > >>> on Apple Mac, > >>> > >> > "/Library/Frameworks/R.framework/Resources/library/survival/html/00Inde > >> x.ht= > >>> ml" > >>> etc.) > >>> > >>> > >>> Details: > >>> --- > >>> > >>> The help() functi
Re: [Rd] Wishlist: Navigate to "Index" page of help when no topic specified (PR#13860)
> -Original Message-
> From: Duncan Murdoch [mailto:murd...@stats.uwo.ca]
> Sent: Tuesday, August 04, 2009 8:03 AM
> To: Steven McKinney
> Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org
> Subject: Re: [Rd] Wishlist: Navigate to "Index" page of help when no
> topic specified (PR#13860)
>
> On 7/28/2009 6:30 PM, smckin...@bccrc.ca wrote:
> > Hi all,
> >
> > When I install a new package, and don't yet know any function names,
> > I have to play the "poor man's game" to get to the standard
> > help system "Index" page for the package:
>
> You could complain to the package author or maintainer, who should have
> created a help alias with the package name so that ?survival would give
> you something useful. But I would guess R 2.10.x or 2.11.x will do
> that
> automatically.
>
> Duncan Murdoch
Unfortunately it happens frequently - hopefully I
don't have to complain so much - I'd rather figure
out code to get to the index page!
When you say "I would guess R 2.10.x or 2.11.x will do
that automatically" do you mean
?survival::
or some similar incantation
will take me to the Index or 00Index page?
Do I need to propose code or is it already
known how to do this within the R core group?
Best
Steve McKinney
>
> > Poor Man's Game -=20
> > Load new package;=20
> > issue search() command;
> > find position (say N) of loaded package;=20
> > issue objects(pos =3D N) command;
> > get name of a random function (san newFunction);=20
> > issue ?newFunction command;
> > scroll to bottom of page;=20
> > click on the "Index" hyperlink
> >
> > There are other variations, but they all involve this=20
> > long march to the Index page.
> >
> >
> > What I'd like to be able to do is enter the command
> >
> >> help(package =3D "survival")
> >
> > or
> >
> >> ?survival::
> >
> > and get the usual hyperlinked help page displayed (the "00Index"
> page)
> > instead of the static "text only" display or an error message
> >
> > (for example, on Windows, this equates to invoking
> > "C:/PROGRA~1/R/R-29~1.1/library/survival/chm/00Index"
> > on Apple Mac,
> >
> "/Library/Frameworks/R.framework/Resources/library/survival/html/00Inde
> x.ht=
> > ml"
> > etc.)
> >
> >
> > Details:
> > ---
> >
> > The help() function returns an object of
> > class "help_files_with_topic".
> > The object consists of a character vector
> > with several attributes.
> >
> > PC: Windows XP
> >
> >> library("survival")
> >> foo <- help("aareg", package =3D "survival")
> >> class(foo)
> > [1] "help_files_with_topic"
> >> foo[1]
> > [1] "C:/PROGRA~1/R/R-29~1.1/library/survival/chm/aareg"
> >> attributes(foo)
> > $call
> > help(topic =3D "aareg", package =3D "survival")
> >
> > $pager
> > [1] "internal"
> >
> > $topic
> > [1] "aareg"
> >
> > $tried_all_packages
> > [1] FALSE
> >
> > $type
> > [1] "chm"
> >
> > $class
> > [1] "help_files_with_topic"
> >
> >> bar <- help("", package =3D "survival")
> >> class(bar)
> > [1] "help_files_with_topic"
> >> bar[1]
> > [1] NA
> >> attributes(bar)
> > $call
> > help(topic =3D "", package =3D "survival")
> >
> > $pager
> > [1] "internal"
> >
> > $topic
> > [1] ""
> >
> > $tried_all_packages
> > [1] FALSE
> >
> > $type
> > [1] "chm"
> >
> > $class
> > [1] "help_files_with_topic"
> >
> > If I alter the character vector to
> > point to "00Index"
> >
> >> bar[1] <- "C:/PROGRA~1/R/R-29~1.1/library/survival/chm/00Index"
> >> bar
> >
> > I see exactly what I've been attempting to achieve.
> >
> >
> > Mac OS X:
> >
> >> foo <- help("aareg", package =3D "survival")
> >> foo[1]
> > [1]
> "/Library/Frameworks/R.framework/Resources/library/survival/html/aareg.
> =
> > html"
> >> attributes(foo)
> > $call
> > help(topic =3D "aareg", package =3D "survival")
> >
> &g
Re: [Rd] linking environments
>
> -Original Message-
> From: r-devel-boun...@r-project.org on behalf of Joerg Betzin
> Sent: Wed 3/25/2009 8:47 AM
> To: r-devel@r-project.org
> Subject: [Rd] linking environments
>
> Dear R-helpers,
>
> I try to use nested R-functions as follows:
Looks like a question for R-help, not R-devel.
It's better to post such questions to the
r-h...@r-project.org mailing list.
>
> help1 = function(){
> x = 1
> help2()
> }
>
> with
>
> help2 = function(){
> if (x == 1)
> cat("Hello world x = 1")
> }
>
> If I compile these functions and run help1()
> an error message occurs
> Fehler in help2() : objekt "x" nicht gefunden
>
> in english "error in help2(): object "x" not found"
>
Why not pass the value of x from help1
to help2?
help1 <- function(){
x <- 1
help2(x)
}
help2 <- function(x){
if (x == 1)
cat("Hello world x = 1")
}
> help1 <- function(){
+ x <- 1
+ help2(x)
+ }
>
>
>
> help2 <- function(x){
+ if (x == 1)
+ cat("Hello world x = 1")
+ }
>
>
>
> help1()
Hello world x = 1>
(No compiling is involved.)
> If I change help1 to
>
> help1 = function(){
> x <<- 1
> help2()
> }
>
> so that "x" is now defined at the global environment it works fine.
> But the problem is, now "x" is defined also outside of help1 and this is
> not desired !
>
> Is there any usable solution for this problem?
> But, the original problem is to assign new values for "x" in help1 inside
> help2 !
Is this a homework problem?
Some reading of
?environment
will help answer this.
>
> Thanks in advance
>
> Jörg Betzin
> -------
> Deutsches Zentrum für Altersfragen
> Manfred-von-Richthofen-Str. 2
> 12101 Berlin
> Tel. (030) 260740-20
> E-Mail: joerg.bet...@dza.de
> URL: http://www.dza.de
> ---
>
> [[alternative HTML version deleted]]
>
Steven McKinney, Ph.D.
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: smckinney +at+ bccrc +dot+ ca
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] p.adjust; n > length(p) (PR#13519)
Hi Ludo,
Issues such as this are best posed as
questions to the list before filing a bug
report. (False bug reports create extra
work for volunteer R-core members.)
What is your use case for setting
n larger than length(p) (the default)?
The documentation does say
"n number of comparisons, must be at least length(p); only set this
(to non-default) when you know what you are doing!"
Because the default
n = length(p)
is not evaluated until n is first needed in
the function body ('lazy evaluation') n is
by default set to length(p) after NAs
are removed in about line 8 of the function
line "stopifnot(n >= length(p))" )
and I'm not finding any problems with the
function, even when supplying p-values with NAs.
The documentation also states
"Note that you can set n larger than length(p) which means the
unobserved p-values are assumed to be greater than all the observed p
for "bonferroni" and "holm" methods and equal to 1 for the other
methods."
so it is up to the user to properly interpret the function
output when using a non-default setting for n. The ensuing warning
is just a warning, not an error, requiring proper interpretation
and understanding by the user that chooses to set n to a non-default
setting.
> -Original Message-
> From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org]
> On Behalf Of lpa...@xs4all.nl
> Sent: Wednesday, February 11, 2009 7:10 AM
> To: r-de...@stat.math.ethz.ch
> Cc: r-b...@r-project.org
> Subject: [Rd] p.adjust; n > length(p) (PR#13519)
>
> Full_Name: Ludo Pagie
> Version: 2.8.1
> OS: linux
> Submission from: (NULL) (194.171.7.39)
>
>
> p.adjust in stats seems to have a bug in handling n>length(p) for (at
> least) the
> methods 'holm' and 'hochberg'.
>
> For method 'holm' the relevant code:
> i <- 1:n
> o <- order(p)
> ro <- order(o)
> pmin(1, cummax((n - i + 1) * p[o]))[ro]
>
> where p is the supplied vector of pvalues and n is the supplied number
of
> comparisons. If n>length(p) p.adjust() gives a warning:
> Warning message:
> In (n - i + 1) * p[o] :
> longer object length is not a multiple of shorter object length
>
> to me it seems that instead of 'i <- 1:n', 'i <- 1:length(p)' is
required.
This is the case if you do not specify n. Lazy evaluation yields
n = length(p)
> Similar cases seem to be true for 'hochberg' and possibly other
methods.
>
> (I tried checking whether this bug has been reported but the website
broke
> on
> me. appologies if the bug is known already)
>
> Best, Ludo
>
> Netherlands Cancer Institute
> Gene Regulation (B4)
> van Steensel Group
> Plesmanlaan 121
> 1066 CX Amsterdam
> The Netherlands
>
> Tel.: ++ 20 512 7986
> Fax: ++ 20 669 1383
> email: lpa...@xs4all.nl
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Best
Steven McKinney, Ph.D.
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: smckin...@bccrc.ca
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n")
gt; is responsible for the newline. Is this really intended? > > > > # separators, not terminators > > > > Another look shows that, contrary to what is said in the help file, > > an element of vector 'sep' is /not/ printed out after each element > > of the vector passed as argument '...' to cat(), "including the last" > > --- confer the for-loop over the elements of '...' in lines 596-617 > > and the print-out of the separator > > > > cat_printsep(sepr, ntot); > > > > in line 600. Once again: Is this intended? > > > > A patch fixing my problem would be easy, though might crash > > other much more important code; would you have any > > proposals? > > > > Best, > > Peter > > > > ------- > > Version: > > platform = i386-pc-mingw32 > > arch = i386 > > os = mingw32 > > system = i386, mingw32 > > status = Under development (unstable) > > major = 2 > > minor = 9.0 > > year = 2008 > > month = 10 > > day = 01 > > svn rev = 46589 > > language = R > > version.string = R version 2.9.0 Under development (unstable) > > (2008-10-01 r46589) > > > > Windows XP (build 2600) Service Pack 3 > > > > Locale: > > LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 > > > > Search Path: > > .GlobalEnv, package:stats, package:graphics, package:grDevices, > > package:utils, package:datasets, package:methods, Autoloads, package:base > > > > __ > > 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 Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre email: smckinney +at+ bccrc +dot+ ca tel: 604-675-8000 x7561 BCCRC Molecular Oncology 675 West 10th Ave, Floor 4 Vancouver B.C. V5Z 1L3 Canada __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Posting Guide
I'd recommend either having two or three good examples of acceptable posts at the end of the posting guide or at least some hyperlinks to good examples. Two or three contrasting poor posts would also be helpful. If people can see a brief email with working code AND the ever-essential sessionInfo() output I think they will be more likely to compose a reasonable post. It's not rocket science when you see a few examples of good posts, but reading lines and lines of text describing a good post clearly is not getting through to many people. Steve McKinney -Original Message- From: [EMAIL PROTECTED] on behalf of Gabor Grothendieck Sent: Fri 6/6/2008 10:30 AM To: R Development List Subject: [Rd] Posting Guide People read the posting guide yet they are still unable to create an acceptable post. e.g. https://stat.ethz.ch/pipermail/r-help/2008-June/164092.html I think the problem is that the guide is not clear or concise enough. I suggest we add a summary at the beginning which gets to the heart of what a poster is expected to provide: Summary To maximize your change of getting a response when posting provide (1) commented, (2) minimal, (3) self-contained and (4) reproducible code. (This one line summary also appears at the end of each message to r-help.) "Self-contained" and "reproducible" mean that a responder can copy the questioner's code to the clipboard, paste it into their R session and see the same problem you as the questioner see. Note that dput(mydata) will display mydata in a reproducible way. Self-contained and reproducible are needed because: (1) Self-Effort. It shows that the questioner tried to solve the problem by themself first. (2) Test framework. Often the responder needs to play with the code a bit in order to respond or at least to give the best answer. They can't do that without a test framework that includes the data and the code to run it and its not fair to ask them to not only answer the question but also to come up with test data and to complete incomplete code. (3) Archives. Questions and answers go into the archives so they are not only for the benefit of of the questioner but also for the benefit of all future searchers of the archive. That means that its not finished if you have solved the problem for yourself. You still need to ensure that the thread has a complete solution. (For that reason its also important to give a meaningful subject to each post.) "Commented" and "minimal" also reduce the time it takes to understand the problem. Don't just dump your code as is into the message since you are just wasting your own time. Its not likely anyone will answer a message if the questioner has not taken the time to reduce it to its essential elements. Surprisingly, quite often understanding what the problem is takes the responder most of the time -- not solving the problem. Once the question is actually understood its often quite fast to answer. Thus in addition to posting it in a minimal form, comment on it sufficiently so that the responder knows what the code does and is intended to produce. It may be obvious to the questioner who is embroiled in the problem but that does not mean its obvious to others. Introduction rest of posting guide ... __ 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] poly() can exceed degree k - 1 for k distinct points (PR#11251)
I haven't parsed the source to fully understand the 'normalization constants' returned in the poly output component attr(,"coefs")$norm2 but notice that the first 6 are non-zero and the last 8 are smaller than machine precision. Some kind of useful warning to the user could ensue upon evaluation of such normalization constants? > x = rep(1:5,3) > x [1] 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 > poly(x, 12) 1 2 3 4 5 6 7 8 9 10 [1,] -3.651484e-01 0.3086067 -1.825742e-01 0.06900656 0.50410540 -0.04690012 0.16698778 0.03700268 -0.21853454 -0.50410540 [2,] -1.825742e-01 -0.1543033 3.651484e-01 -0.27602622 0.11156408 -0.48312338 -0.10874588 -0.02250863 0.27412822 -0.11156408 [3,] -6.437201e-18 -0.3086067 -1.301129e-16 0.41403934 -0.17911692 -0.14493516 0.51592172 0.11434917 0.03151684 0.17911692 [4,] 1.825742e-01 -0.1543033 -3.651484e-01 -0.27602622 0.07326369 0.11056157 -0.07141299 0.52748012 0.18001893 -0.07326369 [5,] 3.651484e-01 0.3086067 1.825742e-01 0.06900656 -0.17121360 -0.25395954 -0.14949152 0.20036589 -0.42074883 0.17121360 [6,] -3.651484e-01 0.3086067 -1.825742e-01 0.06900656 -0.75205270 0.02345006 -0.08349389 -0.01850134 0.10926727 -0.24794730 [7,] -1.825742e-01 -0.1543033 3.651484e-01 -0.27602622 -0.05578204 0.74156169 0.05437294 0.01125431 -0.13706411 0.05578204 [8,] -6.437201e-18 -0.3086067 -8.788409e-17 0.41403934 0.08955846 0.07246758 -0.75796086 -0.05717459 -0.01575842 -0.08955846 [9,] 1.825742e-01 -0.1543033 -3.651484e-01 -0.27602622 -0.03663185 -0.05528079 0.03570650 -0.76374006 -0.09000946 0.03663185 [10,] 3.651484e-01 0.3086067 1.825742e-01 0.06900656 0.08560680 0.12697977 0.07474576 -0.10018295 0.71037442 -0.08560680 [11,] -3.651484e-01 0.3086067 -1.825742e-01 0.06900656 0.24794730 0.02345006 -0.08349389 -0.01850134 0.10926727 0.75205270 [12,] -1.825742e-01 -0.1543033 3.651484e-01 -0.27602622 -0.05578204 -0.25843831 0.05437294 0.01125431 -0.13706411 0.05578204 [13,] -6.437201e-18 -0.3086067 -8.788409e-17 0.41403934 0.08955846 0.07246758 0.24203914 -0.05717459 -0.01575842 -0.08955846 [14,] 1.825742e-01 -0.1543033 -3.651484e-01 -0.27602622 -0.03663185 -0.05528079 0.03570650 0.23625994 -0.09000946 0.03663185 [15,] 3.651484e-01 0.3086067 1.825742e-01 0.06900656 0.08560680 0.12697977 0.07474576 -0.10018295 -0.28962558 -0.08560680 11 12 [1,] 0.04690012 0.16698778 [2,] 0.48312338 -0.10874588 [3,] 0.14493516 0.51592172 [4,] -0.11056157 -0.07141299 [5,] 0.25395954 -0.14949152 [6,] -0.02345006 -0.08349389 [7,] 0.25843831 0.05437294 [8,] -0.07246758 0.24203914 [9,] 0.05528079 0.03570650 [10,] -0.12697977 0.07474576 [11,] -0.02345006 -0.08349389 [12,] -0.74156169 0.05437294 [13,] -0.07246758 -0.75796086 [14,] 0.05528079 0.03570650 [15,] -0.12697977 0.07474576 attr(,"degree") [1] 1 2 3 4 5 6 7 8 9 10 11 12 attr(,"coefs") attr(,"coefs")$alpha [1] 3.00 3.00 3.00 3.00 3.00 1.314957 2.355111 2.973300 4.032925 4.323708 1.314957 2.355111 attr(,"coefs")$norm2 [1] 1.00e+00 1.50e+01 3.00e+01 4.20e+01 4.32e+01 2.468571e+01 1.128824e-28 1.344243e-28 7.418009e-29 9.824087e-27 [11] 1.017082e-32 2.357175e-51 9.543887e-57 6.351670e-57 attr(,"class") [1] "poly" "matrix" Steven McKinney -Original Message- From: [EMAIL PROTECTED] on behalf of John Maindonald Sent: Thu 4/24/2008 5:24 PM To: r-devel@r-project.org Subject: Re: [Rd] R-devel Digest, Vol 62, Issue 24 Actually, this may be a useful feature! It allows calculation of a basis for the orthogonal complement of the space spanned by model.matrix(lm(y ~ poly(x,12)). However, the default ought surely to be to disallow df > k-1 in poly(x,df), where k = length(unique(x)). John Maindonald email: [EMAIL PROTECTED] phone : +61 2 (6125)3473fax : +61 2(6125)5549 Centre for Mathematics & Its Applications, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. On 24 Apr 2008, at 8:00 PM, [EMAIL PROTECTED] wrote: > From: [EMAIL PROTECTED] > Date: 24 April 2008 3:05:28 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Rd] poly() can exceed degree k - 1 for k distinct points > (PR#11251) > > > The poly() function can create more variables than can be fitted when > there are replicated values. In the example below, 'x' has only 5 > distinct values, but I can apparently fit a 12th-degree polynomial > with > no error messages or even nonzero coefficients: > > R> x = rep(1:5,3) > R> y = rnorm(15) > R> lm(y ~ poly(x, 12)) > > Call: > lm(formula = y ~ poly(x, 12)) >
[Rd] 64-bit R-build on Mac OS X 10.4 - make check failures
Hi all,
I compiled 64-bit R on an Apple Mac G5 running OS X, but it failed
make check. Simon Urbanek suggested I post results to R-devel.
> On Nov 6, 2007, at 10:23 PM, Steven McKinney wrote:
>
> > Hi Simon,
> >
> > Would you be able to give more guidance on how to compile 64-bit
> > libiconv for Tiger,
>
> You can get the sources from Apple and compile it:
> http://www.opensource.apple.com/darwinsource/tarballs/other/libiconv-13.2.tar.gz
>
> If you want to save yourself the hassle, my 64-bit build can be
> obtained and installed as follows:
> curl -s http://r.research.att.com/libiconv-quad.tar.gz | \
> sudo tar fvxz - -C /usr/lib
Many thanks to Simon Urbanek for providing a 64-bit libiconv for
use on the Apple Mac OS X platform. This allowed compilation
on the Mac without having to use the '--without-iconv' switch
(for those of us who are not yet proficient at compiling 64-bit
libraries on the Mac).
Compilation of 64-bit R succeeded, but make check did not.
First failure was in ok-errors.R, and generated this output
in ok-errors.Rout.fail
> ## bad infinite recursion / on.exit / ... interactions
> bar <- function() 1+1
> foo <- function() { on.exit(bar()); foo() }
> foo() # now simple "infinite recursion"
*** caught segfault ***
address 0x7fffeff7ffe30, cause 'memory not mapped'
Traceback:
1: foo()
2: foo()
3: foo()
...
2154: foo()
2155: foo()
2156: foo()
aborting ...
Second error was in d-p-q-r-tests.Rout from this test:
## dbeta(*, ncp):
a <- rlnorm(100)
stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
)
## the first gave 0, the 2nd NaN in R <= 2.3.0
and generated this
output in d-p-q-r-tests.Rout.fail
>
> ## dbeta(*, ncp):
> a <- rlnorm(100)
> stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
+ dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
+ )
Error: dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf is not all TRUE
In addition: Warning message:
In dnbeta(x, shape1, shape2, ncp, log) : NaNs produced
Execution halted
Everything else passed, so I'm not sure how serious these failures are.
I'd appreciate any suggestions about how to figure out what caused these
failures (an inappropriate file somewhere in the path, a possible
bug, improper compilation commands etc.)
version information of compiled R (compilation information at end):
> sessionInfo()
R version 2.6.0 Patched (2007-10-29 r43302)
powerpc64-apple-darwin8.10.0
locale:
C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] lme4_0.99875-8Matrix_0.999375-3 lattice_0.17-2
loaded via a namespace (and not attached):
[1] grid_2.6.0 rcompgen_0.1-17
> R.Version()
$platform
[1] "powerpc64-apple-darwin8.10.0"
$arch
[1] "powerpc64"
$os
[1] "darwin8.10.0"
$system
[1] "powerpc64, darwin8.10.0"
$status
[1] "Patched"
$major
[1] "2"
$minor
[1] "6.0"
$year
[1] "2007"
$month
[1] "10"
$day
[1] "29"
$`svn rev`
[1] "43302"
$language
[1] "R"
$version.string
[1] "R version 2.6.0 Patched (2007-10-29 r43302)"
> .Platform
$OS.type
[1] "unix"
$file.sep
[1] "/"
$dynlib.ext
[1] ".so"
$GUI
[1] "X11"
$endian
[1] "big"
$pkgType
[1] "source"
$path.sep
[1] ":"
$r_arch
[1] ""
>
I built 64-bit R on Mac OS X 10.4.10 with these commands:
export
PATH='/usr/local/lib64/X11/bin:/usr/local/lib64/X11/etc:/usr/local/lib64/X11/include:/usr/local/lib64/X11/lib:/usr/lib:/usr/bin:/usr/local/sbin:/usr/local/bin:/bin:/usr/sbin:/sbin:/usr/local/teTeX/bin/powerpc-apple-darwin-current:~/perl:~/bin'
./configure --host=powerpc64-apple-darwin8.10.0
--build=powerpc64-apple-darwin8.10.0 \
--prefix=/usr/local/lib64 'CC=gcc-4.0 -arch ppc64' 'CXX=g++ -arch ppc64' \
'FC=gfortran-4.0 -arch ppc64' 'F77=gfortran-4.0 -arch ppc64' \
'CFLAGS=-g -O3 -mtune=G5 -mcpu=G5' 'FFLAGS=-g -O3 -mtune=G5 -mcpu=G5' \
'LDFLAGS=-arch ppc64 -m64 -L/usr/local/lib' 'CXXFLAGS=-g -O3 -mtune=G5
-mcpu=G5' \
'FCFLAGS=-g -O3 -mtune=G5 -mcpu=G5' --disable-R-framework --enable-R-shlib \
'--with-blas=-framework vecLib' --with-lapack 1>
configure.R.ppc64.out.20071107.Run01.txt 2>&1
sudo make 1> make.R.ppc64.out.20071107.Run01.txt 2>&1
sudo make check 1> make.check.R.ppc64.out.20071107.Run01.txt 2>&1
Steve McKinney
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Friday question: negative zero
Seems the same on this Apple Mac OSX platform:
> y <- 0
> 1/y
[1] Inf
> y <- -y
> 1/y
[1] -Inf
> x <- complex(real = -1)
> x
[1] -1+0i
> 1/x
[1] -1+0i
> x^(1/3)
[1] 0.5+0.8660254i
> (1/x)^(1/3)
[1] 0.5-0.8660254i
> sessionInfo()
R version 2.5.1 (2007-06-27)
powerpc-apple-darwin8.9.1
locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets" "methods"
"base"
> system("uname -a")
Darwin Dapple.local 8.10.0 Darwin Kernel Version 8.10.0: Wed May 23 16:50:59
PDT 2007; root:xnu-792.21.3~1/RELEASE_PPC Power Macintosh powerpc
> version
_
platform powerpc-apple-darwin8.9.1
arch powerpc
os darwin8.9.1
system powerpc, darwin8.9.1
status
major 2
minor 5.1
year 2007
month 06
day27
svn rev 42083
language R
version.string R version 2.5.1 (2007-06-27)
Steven McKinney
-Original Message-
From: [EMAIL PROTECTED] on behalf of Duncan Murdoch
Sent: Fri 8/31/2007 5:39 PM
To: R Devel
Subject: [Rd] Friday question: negative zero
The IEEE floating point standard allows for negative zero, but it's hard
to know that you have one in R. One reliable test is to take the
reciprocal. For example,
> y <- 0
> 1/y
[1] Inf
> y <- -y
> 1/y
[1] -Inf
The other day I came across one in complex numbers, and it took me a
while to figure out that negative zero was what was happening:
> x <- complex(real = -1)
> x
[1] -1+0i
> 1/x
[1] -1+0i
> x^(1/3)
[1] 0.5+0.8660254i
> (1/x)^(1/3)
[1] 0.5-0.8660254i
(The imaginary part of 1/x is negative zero.)
As a Friday question: are there other ways to create and detect
negative zero in R?
And another somewhat more serious question: is the behaviour of
negative zero consistent across platforms? (The calculations above were
done in Windows in R-devel.)
Duncan Murdoch
__
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] Embedded nuls in strings
I get similar results on an Apple Mac G5
running OS X, though nchar() works.
> raw0 <- as.raw(c(65:68, 0 , 70))
> string0 <- rawToChar(raw0)
> raw0
[1] 41 42 43 44 00 46
> string0
[1] "ABCD\0F"
> nchar(string0)
[1] 6
> grep("F", string0)
integer(0)
> strsplit(string0, split=NULL, fixed=TRUE)[[1]]
[1] "A" "B" "C" "D"
> tolower(string0)
[1] "abcd"
> chartr("F", "x", string0)
[1] "ABCD"
> substr(string0, 6, 6)
[1] ""
>
> sessionInfo()
R version 2.5.1 (2007-06-27)
powerpc-apple-darwin8.9.1
locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
attached base packages:
[1] "splines" "stats" "graphics" "grDevices" "utils" "datasets"
"methods" "base"
>
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: smckinney +at+ bccrc +dot+ ca
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
-Original Message-
From: [EMAIL PROTECTED] on behalf of Herve Pages
Sent: Tue 8/7/2007 2:06 PM
To: r-devel@r-project.org
Subject: [Rd] Embedded nuls in strings
Hi,
?rawToChar
'rawToChar' converts raw bytes either to a single character string
or a character vector of single bytes. (Note that a single
character string could contain embedded nuls.)
Allowing embedded nuls in a string might be an interesting experiment but it
seems to cause some troubles to most of the string manipulation functions.
A string with an embedded 0:
raw0 <- as.raw(c(65:68, 0 , 70))
string0 <- rawToChar(raw0)
> string0
[1] "ABCD\0F"
nchar() should return 6:
> nchar(string0)
[1] 4
In addition this embedded nul seems to break almost all string
manipulation/searching
functions:
grep("F", string0)
strsplit(string0, split=NULL, fixed=TRUE)[[1]]
tolower(string0)
chartr("F", "x", string0)
substr(string0, 6, 6)
...
etc...
Not very surprisingly, they all seem to treat string0 as if it was "ABCD"!
Cheers,
H.
__
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] model.matrix bug? Nested factor yields singular design matrix.
Apologies - I forgot the session info.
> sessionInfo()
R version 2.5.0 (2007-04-23)
powerpc-apple-darwin8.9.1
locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets" "methods"
"base"
other attached packages:
lme4 Matrix lattice
"0.99875-0" "0.99875-1" "0.15-5"
-Original Message-
From: [EMAIL PROTECTED] on behalf of Steven McKinney
Sent: Thu 5/17/2007 11:41 AM
To: r-devel@r-project.org
Subject: [Rd] model.matrix bug? Nested factor yields singular design matrix.
Hi all,
I believe this is a bug in the model.matrix function.
I'd like a second opinion before filing a bug report.
If I have a nested covariate B with multiple values for
just one level of A, I can not get a non-singular design
matrix out of model.matrix
> df <- data.frame(A = factor(c("a", "a", "x", "x"), levels = c("x", "a")),
+ B = factor(c("b", "x", "x", "x"), levels = c("x", "b")))
>
> df
A B
1 a b
2 a x
3 x x
4 x x
So of course the full design matrix is singular,
this is expected.
> model.matrix(~ A * B, df)
(Intercept) Aa Bb Aa:Bb
1 1 1 1 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 3
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
I'd like to drop the B main effect column,
but get the unexpected result of a column of zeroes.
> model.matrix(~ A * B - B, df)
(Intercept) Aa Ax:Bb Aa:Bb
1 1 1 0 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 2
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
>
>
This does not happen in S-PLUS.
> info()
S info file C:\DOCUME~1\kilroy\LOCALS~1\Temp\S0107EB.tmp will be removed at
session end
$Sinfo:
Enterprise Developer Version 7.0.6 for Microsoft Windows : 2005
SHOME:
C:/PROGRAMFILES/INSIGHTFUL/splus70
prog.name: SPLUS.EXE
load.date: Sun Dec 04 23:15:59 2005
date: Thu May 17 07:38:16 PDT 2007
> options(contrasts = c("contr.treatment", "contr.poly"))
> df <- data.frame(A = factor(c("a", "a", "x", "x"), levels = c("x", "a")),
+ B = factor(c("b", "x", "x", "x"), levels = c("x", "b")))
> model.matrix(~ A * B - B, df)
(Intercept) A A:B
1 1 1 1
2 1 1 0
3 1 0 0
4 1 0 0
>
This is what I was expecting to get in R, but can not.
Alternate specifications in R continue to yield a singular
design matrix
>
> model.matrix(~ A/B, df)
(Intercept) Aa Ax:Bb Aa:Bb
1 1 1 0 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 2
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
> model.matrix(~ A + A:B, df)
(Intercept) Aa Ax:Bb Aa:Bb
1 1 1 0 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 2
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
Why is the Ax:Bb column being included?
Have I missed a control parameter or some other way
of specifying to model.matrix not to include this
extra column?
Any feedback appreciated.
Best regards
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
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] model.matrix bug? Nested factor yields singular design matrix.
Hi all,
I believe this is a bug in the model.matrix function.
I'd like a second opinion before filing a bug report.
If I have a nested covariate B with multiple values for
just one level of A, I can not get a non-singular design
matrix out of model.matrix
> df <- data.frame(A = factor(c("a", "a", "x", "x"), levels = c("x", "a")),
+ B = factor(c("b", "x", "x", "x"), levels = c("x", "b")))
>
> df
A B
1 a b
2 a x
3 x x
4 x x
So of course the full design matrix is singular,
this is expected.
> model.matrix(~ A * B, df)
(Intercept) Aa Bb Aa:Bb
1 1 1 1 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 3
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
I'd like to drop the B main effect column,
but get the unexpected result of a column of zeroes.
> model.matrix(~ A * B - B, df)
(Intercept) Aa Ax:Bb Aa:Bb
1 1 1 0 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 2
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
>
>
This does not happen in S-PLUS.
> info()
S info file C:\DOCUME~1\kilroy\LOCALS~1\Temp\S0107EB.tmp will be removed at
session end
$Sinfo:
Enterprise Developer Version 7.0.6 for Microsoft Windows : 2005
SHOME:
C:/PROGRAMFILES/INSIGHTFUL/splus70
prog.name: SPLUS.EXE
load.date: Sun Dec 04 23:15:59 2005
date: Thu May 17 07:38:16 PDT 2007
> options(contrasts = c("contr.treatment", "contr.poly"))
> df <- data.frame(A = factor(c("a", "a", "x", "x"), levels = c("x", "a")),
+ B = factor(c("b", "x", "x", "x"), levels = c("x", "b")))
> model.matrix(~ A * B - B, df)
(Intercept) A A:B
1 1 1 1
2 1 1 0
3 1 0 0
4 1 0 0
>
This is what I was expecting to get in R, but can not.
Alternate specifications in R continue to yield a singular
design matrix
>
> model.matrix(~ A/B, df)
(Intercept) Aa Ax:Bb Aa:Bb
1 1 1 0 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 2
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
> model.matrix(~ A + A:B, df)
(Intercept) Aa Ax:Bb Aa:Bb
1 1 1 0 1
2 1 1 0 0
3 1 0 0 0
4 1 0 0 0
attr(,"assign")
[1] 0 1 2 2
attr(,"contrasts")
attr(,"contrasts")$A
[1] "contr.treatment"
attr(,"contrasts")$B
[1] "contr.treatment"
Why is the Ax:Bb column being included?
Have I missed a control parameter or some other way
of specifying to model.matrix not to include this
extra column?
Any feedback appreciated.
Best regards
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Minor logical bug in rbind.data.frame ?
<- attr(xi, "row.names")
ni <- length(ri)
if (is.null(clabs))
clabs <- names(xi)
else {
pi <- match.names(clabs, names(xi))
if (!is.null(pi))
perm[[i]] <- pi
}
rows[[i]] <- seq.int(from = nrow + 1, length = ni)
rlabs[[i]] <- Make.row.names(nmi, ri, ni, nrow)
nrow <- nrow + ni
if (is.null(value)) {
value <- unclass(xi)
nvar <- length(value)
all.levs <- vector("list", nvar)
has.dim <- logical(nvar)
facCol <- logical(nvar)
ordCol <- logical(nvar)
for (j in 1:nvar) {
xj <- value[[j]]
if (!is.null(levels(xj))) {
all.levs[[j]] <- levels(xj)
facCol[j] <- TRUE
}
else facCol[j] <- is.factor(xj)
ordCol[j] <- is.ordered(xj)
has.dim[j] <- length(dim(xj)) == 2
}
}
else for (j in 1:nvar) {
xij <- xi[[j]]
if (is.null(pi) || is.na(jj <- pi[[j]]))
jj <- j
if (facCol[jj]) {
if (length(lij <- levels(xij)) > 0) {
all.levs[[jj]] <- unique(c(all.levs[[jj]],
lij))
ordCol[jj] <- ordCol[jj] & is.ordered(xij)
}
else if (is.character(xij))
all.levs[[jj]] <- unique(c(all.levs[[jj]],
xij))
}
}
}
else if (is.list(xi)) {
ni <- range(sapply(xi, length))
if (ni[1] == ni[2])
ni <- ni[1]
else stop("invalid list argument: all variables should have the
same length")
rows[[i]] <- ri <- as.integer(seq.int(from = nrow +
1, length = ni))
nrow <- nrow + ni
rlabs[[i]] <- Make.row.names(nmi, ri, ni, nrow)
if (length(nmi <- names(xi)) > 0) {
if (is.null(clabs))
clabs <- nmi
else {
tmp <- match.names(clabs, nmi)
if (!is.null(tmp))
perm[[i]] <- tmp
}
}
}
else if (length(xi) > 0) {
rows[[i]] <- nrow <- nrow + 1
rlabs[[i]] <- if (nchar(nmi) > 0)
nmi
else as.integer(nrow)
}
}
nvar <- length(clabs)
if (nvar == 0)
nvar <- max(sapply(allargs, length))
if (nvar == 0)
return(structure(list(), class = "data.frame", row.names = integer()))
pseq <- 1:nvar
if (is.null(value)) {
value <- list()
value[pseq] <- list(logical(nrow))
}
names(value) <- clabs
for (j in 1:nvar) if (length(lij <- all.levs[[j]]) > 0)
value[[j]] <- factor(as.vector(value[[j]]), lij, ordered = ordCol[j])
if (any(has.dim)) {
rmax <- max(unlist(rows))
for (i in (1:nvar)[has.dim]) if (!inherits(xi <- value[[i]],
"data.frame")) {
dn <- dimnames(xi)
rn <- dn[[1]]
if (length(rn) > 0)
length(rn) <- rmax
pi <- dim(xi)[2]
length(xi) <- rmax * pi
value[[i]] <- array(xi, c(rmax, pi), list(rn, dn[[2]]))
}
}
for (i in 1:n) {
xi <- unclass(allargs[[i]])
if (!is.list(xi))
if (length(xi) != nvar)
xi <- rep(xi, length.out = nvar)
ri <- rows[[i]]
pi <- perm[[i]]
if (is.null(pi))
pi <- pseq
for (j in 1:nvar) {
jj <- pi[j]
xij <- xi[[j]]
if (has.dim[jj]) {
value[[jj]][ri, ] <- xij
rownames(value[[jj]])[ri] <- rownames(xij)
}
else {
value[[jj]][ri] <- if (is.factor(xij))
as.vector(xij)
else xij
if (!is.null(nm <- names(xij)))
names(value[[jj]])[ri] <- nm
}
}
}
rlabs <- unlist(rlabs)
if (any(duplicated(rlabs)))
rlabs <- make.unique(as.character(unlist(rlabs)), sep = "")
if (is.null(cl)) {
as.data.frame(value, row.names = rlabs)
}
else {
class(value) <- cl
attr(value, "row.names") <- rlabs
value
}
}
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rm() deletes 'c' if c('a','b') is the argument (PR#9399)
The argument should indeed be made.
I think the documentation for rm() needs
to be changed to:
Arguments:
...: the object to be removed, supplied individually. Multiple objects
must be supplied via the list argument.
>From the rm() help page:
rm(..., list = character(0), pos = -1,
envir = as.environment(pos), inherits = FALSE)
Arguments
... the objects to be removed, supplied individually and/or as a character
vector
> class(c('a', 'b'))
[1] "character"
>
> length(c('a', 'b'))
[1] 2
> is.vector(c('a', 'b'))
[1] TRUE
>
By all appearances, c('a', 'b') seems
to be a character vector. I'm not the
most knowledgeable R programmer, so I'm not
sure what I'm missing here.
I haven't delved deeply into the rm() source code, but
this looks like a logical bug. The documentation
needs to be modified to fit the current function
behaviour, or the current function behaviour needs
to be modified to fit the documentation.
> rm(c('a', 'b'))
Warning message:
remove: variable "c" was not found
Why is "c" ending up in the list of items to remove?
(see PS: below)
> unlist(list('a', 'b'))
[1] "a" "b"
> class(unlist(list('a', 'b')))
[1] "character"
> is.vector(unlist(list('a', 'b')))
[1] TRUE
> a <- 1
> b <- 2
> rm(unlist(list('a', 'b')))
Warning messages:
1: remove: variable "unlist" was not found
2: remove: variable "list("a", "b")" was not found
> ls()
[1] "a""b""d""getMonograph" "last.warning"
"myfun"
>
Does the rm() doc need modification?
Presently it appears that the doc should read
Arguments:
...: the object to be removed, supplied individually. Multiple objects
must be supplied via the list argument.
PS:
Does it have anything to do with this
type of behaviour? Is this essentially
what is happening in the match.call()
in rm()?
> sapply(substitute(c('a', 'b')), as.character)
[1] "c" "a" "b"
> rm
function (..., list = character(0), pos = -1, envir = as.environment(pos),
inherits = FALSE)
{
names <- sapply(match.call(expand.dots = FALSE)$..., as.character)
if (length(names) == 0)
names <- character(0)
list <- .Primitive("c")(list, names)
.Internal(remove(list, envir, inherits))
}
> sapply(c('a', 'b'), as.character)
a b
"a" "b"
> sapply(substitute(c('a', 'b')), as.character)
[1] "c" "a" "b"
> match.call
function (definition = NULL, call = sys.call(sys.parent()), expand.dots = TRUE)
.Internal(match.call(definition, call, expand.dots))
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
-Original Message-
From: James W. MacDonald [mailto:[EMAIL PROTECTED]
Sent: Wed 11/29/2006 11:14 AM
To: Steven McKinney
Cc: [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
Subject: Re: [Rd] rm() deletes 'c' if c('a','b') is the argument (PR#9399)
That's because you are not using rm() correctly. From the help page:
Arguments:
...: the objects to be removed, supplied individually and/or as a
character vector
list: a character vector naming objects to be removed.
So if you pass an unnamed argument, rm() will assume you have some
objects in the .GlobalEnv with those names that you would like to
remove. If you want to pass a character vector, you have to name it
because the first argument is '...'.
> a <- 1:5
> b <- 2:10
> c <- "not a good variable name"
> rm(list=c("a","b"))
> c
[1] "not a good variable name"
> a <- 1:5
> b <- 2:10
> c <- "still not a good variable name"
> rm(a,b)
> c
[1] "still not a good variable name"
> a <- 1:5
> b <- 2:10
> c <- "still not a good variable name"
> rm("a","b")
> c
[1] "still not a good variable name"
NB: 'c' is not a good variable name because you are masking an existing
function.
An argument could be made that the explanation for the first argument is
not very exact.
Best,
Jim
Steven McKinney wrote:
> Same behaviour seen on Apple Mac OSX 10.4.8 platform:
>
Re: [Rd] rm() deletes 'c' if c('a','b') is the argument (PR#9399)
Same behaviour seen on Apple Mac OSX 10.4.8 platform:
> sessionInfo()
R version 2.4.0 Patched (2006-10-31 r39758)
powerpc-apple-darwin8.8.0
locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
"base"
other attached packages:
XML
"1.2-0"
>
> ls()
[1] "getMonograph" "last.warning" "myfun"
> a <- 1
> b <- 2
> c <- letters
> a
[1] 1
> b
[1] 2
> c
[1] "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r"
"s" "t" "u" "v" "w" "x" "y" "z"
> rm(c('a', 'b'))
> a
Error: object "a" not found
> b
Error: object "b" not found
> c
.Primitive("c")
> ls()
[1] "getMonograph" "last.warning" "myfun"
> a <- 1
> b <- 2
> d <- letters
> ls()
[1] "a""b""d""getMonograph" "last.warning"
"myfun"
> rm(c('a', 'b'))
Warning message:
remove: variable "c" was not found
> ls()
[1] "d""getMonograph" "last.warning" "myfun"
>
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
-Original Message-
From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]
Sent: Wed 11/29/2006 10:35 AM
To: r-devel@stat.math.ethz.ch
Cc: [EMAIL PROTECTED]
Subject: [Rd] rm() deletes 'c' if c('a','b') is the argument (PR#9399)
Full_Name: Lixin Han
Version: 2.4.0
OS: Windows 2000
Submission from: (NULL) (155.94.110.222)
A character vector c('a','b') is supplied to rm(). As a result, 'c' is deleted
unintentionally.
> a <- 1:5
> b <- 'abc'
> c <- letters
> ls()
[1] "a" "b" "c"
> rm(c('a','b'))
> ls()
character(0)
>
__
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] Bug in Acrobat Reader 7 (or R?) with translucent text
Hi Kevin,
On my Mac, (PowerPC OS X 10.4.8)
I see the same plot in Adobe reader and
in the Mac preview app.
Text is transluscent when overlaid by a plot icon.
Text is not transluscent when overlaid by other text. (Is
this expected?)
Plot icons are transluscent when overlaid by
other plot icons.
Adobe is buggy! (I have trouble with Adobe rendering
a pdf containing four scatterplots with 38
data points each, though the Mac preview.app
can render them properly.)
Good luck filing a bug report with Adobe :(
Adobe:
Version 7.0.8 5/16/2006
R:
> sessionInfo()
R version 2.4.0 (2006-10-03)
powerpc-apple-darwin8.7.0
locale:
en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
-Original Message-
From: [EMAIL PROTECTED] on behalf of Kevin Wright
Sent: Thu 10/19/2006 1:14 PM
To: r-devel@stat.math.ethz.ch
Subject: [Rd] Bug in Acrobat Reader 7 (or R?) with translucent text
My setup: R 2.4.0, Windows 2000, Acrobat Reader 7.
When I create a .pdf with translucent colors, the translucency works
correctly for points, but not for text. Below is some R code that
creates a .pdf with this phenomenon.
I was going to report this as a bug in R, but then I tried to view the
pdf with a couple of other viewers and found that at least one of the
viewers correctly displayed the file (with translucent text), so maybe
it is a bug with Acrobat Reader. It might be worth checking to see if
colors for "text" are handled any differently than colors for "points"
that might cause this problem.
Best,
Kevin Wright
black <- rgb(0,0,0,.75)
blue <- rgb(0, .2, 1, .75)
red <- rgb(1,0,0,.75)
pdf("pdfcols.pdf", version="1.4")
set.seed(50)
plot(.5,.5,type="n",xlim=c(0,1),ylim=c(0,1))
points(runif(200),runif(200), col=black)
points(runif(200),runif(200), col=blue)
points(runif(200),runif(200), col=red)
text(.1, .1, "This is red", col=red)
text(.1, .1, "Also red", col=red)
text(.2, .2, "This is blue", col=blue)
text(.2, .2, "Also blue", col=blue)
text(.3, .3, "This is black", col=black)
text(.3, .3, "Also black", col=black)
points(runif(200),runif(200), col=black)
points(runif(200),runif(200), col=blue)
points(runif(200),runif(200), col=red)
dev.off()
__
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] boxplot, notches, etc.
Hi Ben, I like the odd looking notches, they reveal that the data comprising the box plot need more careful review. Tukey et al (1) comment that "It should be noted that the convention has been adopted that, should the notch lie outside either hinge, an unnotched box, plotted with dashed lines, is displayed for that group indicating low confidence in it." While this convention appears to have been abandoned, the wierd-looking notches indicate a group with odd behaviour warranting more careful consideration. So I vote to retain odd-looking notches. Et al and Tukey (1) discuss their reasoning and empirical findings as to the formulation for the notch width. They used median +/- 1.7(1.25R/1.35sqrt(N)) which reduces to median +/- 1.574*(IQR)/sqrt(N) Perhaps similar reasoning can resolve the issue of notches for boxplots of log(y)? I'll see if I can work through the normal - lognormal transformation machinery and propose a reasonable notch strategy for the log(y) case. Maybe someone out there has already done so? (1) R. McGill, J. Tukey, W. Larsen (1978) "Variations of Box Plots" The American Statistician, Vol. 32, No. 1, pp 12-16 http://www.jstor.org/view/00031305/di020553/02p0045u/0 Cheers Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre email: [EMAIL PROTECTED] tel: 604-675-8000 x7561 BCCRC Molecular Oncology 675 West 10th Ave, Floor 4 Vancouver B.C. V5Z 1L3 Canada -Original Message- From: [EMAIL PROTECTED] on behalf of Ben Bolker Sent: Tue 10/17/2006 6:09 AM To: r-devel@stat.math.ethz.ch Subject: Re: [Rd] boxplot, notches, etc. Ben Bolker zoo.ufl.edu> writes: > > Synopsis: boxplot notches look weird when notches > are greater than hinges ((1.58*IQR/sqrt(n)) > approx IQR). > When log="y" this causes an error. Below are several > reproducible examples, some discussion, and a patch against > calc.R. > > Please feel free to say "this is just cosmetic/isn't an issue, go > away" ... > > cheers > Ben Bolker > followup (one week later): does anyone have any opinions on this ... ??? (If someone will tell me this isn't worth pursuing, I will give up on it) Ben Bolker __ 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] getMethods() not finding all methods
Hi Seth,
Thanks for the info - actually one of the things
I like about getMethods is seeing the function
internals - as you point out, geneNames is being
deprecated in favour of featureNames, which is
revealed by the guts of the geneNames method ;)
> getMethods("geneNames")
An object of class MethodsList
Slot "methods":
$ExpressionSet
Method Definition:
function (object)
{
.Deprecated("featureNames")
featureNames(object)
}
Signatures:
object
target "ExpressionSet"
defined "ExpressionSet"
-Original Message-
From: [EMAIL PROTECTED] on behalf of Seth Falcon
Sent: Thu 10/12/2006 5:28 PM
To: r-devel@stat.math.ethz.ch
Subject: Re: [Rd] getMethods() not finding all methods
"Steven McKinney" <[EMAIL PROTECTED]> writes:
> Running R2.4.0 on Apple Mac OS X 10.4.8,
> in Emacs ESS mode, and also R.app.
>
>
> In an attempt to learn a bit more about
> a particular method (geneNames in package affy)
> I invoked
>
> getMethods("geneNames")
>
> which produced geneNames methods, but not the
> one in affy (output below).
>
> I had to know the signature (AffyBatch) in order
> to find the method
>
>> getMethod("geneNames", "AffyBatch")
>
> Isn't getMethods() supposed to get them all?
>
> Is this a problem, or bug, or am I misunderstanding
> something?
>
> I try to use getMethods() to learn how things work,
> without having to always get the source code and
> grep my way through the source. Is there another
> way to get all methods that I should be using?
>
> Any info appreciated.
I think it may be a bug in getMethods. At least, I would expect it to
show the AffyBatch method. The output of showMethods is, IMO, more
readable and, in this case, more useful:
> library(affy)
[snip]
> showMethods("geneNames")
Function: geneNames (package Biobase)
object="AffyBatch"
object="ExpressionSet"
object="exprSet"
As an aside, geneNames is deprecated in favor of featureNames, a
somewhat more "P.C." term for the things measured on the chips :-)
Best,
+ seth
__
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] getMethods() not finding all methods
Running R2.4.0 on Apple Mac OS X 10.4.8,
in Emacs ESS mode, and also R.app.
In an attempt to learn a bit more about
a particular method (geneNames in package affy)
I invoked
getMethods("geneNames")
which produced geneNames methods, but not the
one in affy (output below).
I had to know the signature (AffyBatch) in order
to find the method
> getMethod("geneNames", "AffyBatch")
Isn't getMethods() supposed to get them all?
Is this a problem, or bug, or am I misunderstanding
something?
I try to use getMethods() to learn how things work,
without having to always get the source code and
grep my way through the source. Is there another
way to get all methods that I should be using?
Any info appreciated.
> library(affy)
Loading required package: Biobase
Loading required package: tools
Welcome to Bioconductor
Vignettes contain introductory material. To view, type
'openVignette()' or start with 'help(Biobase)'. For details
on reading vignettes, see the openVignette help page.
Loading required package: affyio
> getMethods("geneNames")
An object of class MethodsList
Slot "methods":
$ExpressionSet
Method Definition:
function (object)
{
.Deprecated("featureNames")
featureNames(object)
}
Signatures:
object
target "ExpressionSet"
defined "ExpressionSet"
$exprSet
Method Definition:
function (object)
featureNames(object)
Signatures:
object
target "exprSet"
defined "exprSet"
Slot "argument":
object
Slot "allMethods":
$ExpressionSet
Method Definition:
function (object)
{
.Deprecated("featureNames")
featureNames(object)
}
Signatures:
object
target "ExpressionSet"
defined "ExpressionSet"
$exprSet
Method Definition:
function (object)
featureNames(object)
Signatures:
object
target "exprSet"
defined "exprSet"
> search()
[1] ".GlobalEnv""package:affy" "package:affyio"
"package:Biobase" "package:tools" "tools:RGUI"
[7] "package:methods" "package:stats" "package:graphics"
"package:grDevices" "package:utils" "package:datasets"
[13] "Autoloads" "package:base"
> getMethod("geneNames", "AffyBatch")
Method Definition:
function (object)
{
cdf.envir <- getCdfInfo(object)
return(ls(env = cdf.envir))
}
Signatures:
object
target "AffyBatch"
defined "AffyBatch"
>
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug/problem reporting: Possible to modify posting guide FAQ?
If users post a bug or problem issue to an R-based news group
(R-devel, R-help, BioC - though BioC is far more forgiving)
they get yelled at for not reading the posting guide
and FAQ.
"Please *_do_* read the FAQ, the posting guide, ..."
the yellers do say. So I read the BioC FAQ and it says...
http://www.bioconductor.org/docs/faq/
"Bug reports on packages should perhaps be sent to the
package maintainer rather than to r-bugs."
So I send email to a maintainer, who I believe rightly points out
"best to send this kind of questions to the bioc mailing list, rather
than to myself privately, because other people might (a) also have
answers or (b) benefit from the questions & answers."
Could the FAQ possibly be revised to some sensible combination
that generates less finger pointing, such as
"Bug reports on packages should be sent to the Bioconductor mailing list,
and sent or copied to the package maintainer, rather than to r-bugs."
or
"Bug reports on packages should be sent to the package maintainer,
and copied to the Bioconductor mailing list, rather than to r-bugs."
Could the posting guides to R-help and R-devel do something
similar?
Sign me
http://www.r-project.org/posting-guide.html
"If the question relates to a contributed package , e.g., one downloaded
from CRAN, try contacting the package maintainer first. You can also
use find("functionname") and packageDescription("packagename") to
find this information. Only send such questions to R-help or R-devel if
you get no reply or need further assistance. This applies to both
requests for help and to bug reports."
How about
If the question relates to a contributed package , e.g., one downloaded
from CRAN, email the list and be sure to additionally send to or copy to
the package maintainer as well. You can use find("functionname")
and packageDescription("packagename") to find this information.
Only send such questions to one of R-help or R-devel. This applies to both
requests for help and to bug reports.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How do I modify an exported function in a locked environment?
Running R.app on Mac OS X 10.4
> version
_
platform powerpc-apple-darwin8.6.0
arch powerpc
os darwin8.6.0
system powerpc, darwin8.6.0
status
major 2
minor 3.1
year 2006
month 06
day01
svn rev38247
language R
version.string Version 2.3.1 (2006-06-01)
>
I am trying to learn how to modify functions
in a locked environment.
For an example, suppose I'm using the package "zoo".
zoo contains function "rollmean.default"
> rollmean.default
function (x, k, na.pad = FALSE, align = c("center", "left", "right"),
...)
{
x <- unclass(x)
n <- length(x)
y <- x[k:n] - x[c(1, 1:(n - k))]
y[1] <- sum(x[1:k])
rval <- cumsum(y)/k
if (na.pad) {
rval <- switch(match.arg(align), left = {
c(rval, rep(NA, k - 1))
}, center = {
c(rep(NA, floor((k - 1)/2)), rval, rep(NA, ceiling((k -
1)/2)))
}, right = {
c(rep(NA, k - 1), rval)
})
}
return(rval)
}
Suppose for whatever reason I want output to be
in percent, so I'd like to modify the result to be
rval <- 100 * cumsum(y)/k
I cannot just copy the function and change it, as the namespace
mechanism ensures the rollmean.default in 'zoo' continues to be used.
If I use
fixInNamespace("rollmean.default", ns = "zoo")
I can edit the rval <- cumsum(y)/k line to read
rval <- 100 * cumsum(y)/k
save the file and exit the R.app GUI editor.
But this does not update the exported copy of the
function (the documentation for fixInNamespace says
this is the case) - how do I accomplish this last step?
If I list the function after editing, I see the original
copy. But if I reinvoke the editor via fixInNamespace(),
I do see my modification.
Where is my copy residing? How do I push it out
to replace the exported copy?
Is this the proper way to modify a package function?
Are there other ways? I've searched webpages, R news,
help files and have been unable to find out how to
get this process fully completed.
Any guidance appreciated.
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [BioC] Errors using biocLite on Apple OS X
The warnings from
make.packages.html()
on the Apple Mac OS X platform can be dealt
with as follows:
(1)
make.packages.html() uses the function tempdir()
and attempts to create a temporary
directory in the default location /tmp/
which fails due to the /tmp directory
architecture on the Mac.
I set up a .Renviron file in my user account directory,
/Users/stevenmckinney/.Renviron
containing the *nix environment variable
TMPDIR="/Users/stevenmckinney/tmp"
Now the tempdir() function returns a directory
in a location that my user account has write access to:
> tempdir()
[1] "/Users/stevenmckinney/tmp/Rtmp1zKvhp"
(2)
The function make.packages.html() attempts to
create a couple of files, but fails on Mac OS X.
Apparently a directory must already exist for file.create()
to successfully establish a new file in it.
> make.packages.html
function (lib.loc = .libPaths())
{
f.tg <- file.path(tempdir(), ".R/doc/html/packages.html")
if (!file.create(f.tg)) {
warning("cannot create HTML package index")
return(FALSE)
}
searchindex <- file.path(tempdir(), ".R/doc/html/search/index.txt")
if (!file.create(searchindex)) {
warning("cannot create HTML search index")
return(FALSE)
}
useUTF8 <- capabilities("iconv")
I modified the two file.create() bits to also include
a directory create. On Mac OS X, you have to specify
the recursive arg to the dir.create() function, or it
will fail to create a subdirectory several levels deep.
First check if the subdirectory exists; if not, create it;
then create the file within it.
make.packages.html <-
function (lib.loc = .libPaths())
{
f.tg <- file.path(tempdir(), ".R/doc/html/packages.html")
if (!((file.exists(dirname(f.tg)) ||
dir.create(dirname(f.tg), recursive = TRUE)) &&
file.create(f.tg))) {
warning("cannot create HTML package index")
return(FALSE)
}
searchindex <- file.path(tempdir(), ".R/doc/html/search/index.txt")
if (!((file.exists(dirname(searchindex)) ||
dir.create(dirname(searchindex), recursive = TRUE)) &&
file.create(searchindex))) {
warning("cannot create HTML search index")
return(FALSE)
}
useUTF8 <- capabilities("iconv")
When I run this redefined version, it runs to completion
without warning.
However, when biocLite() runs, it does not access my
redefined make.packages.html() in .Globalenv - the
bioclite() call appears to always call the package:utils
copy of this function.
Perhaps such modifications could be done by package:utils
developers?
Thanks to Herve Pages for his excellent
summarization of the issues arising when
running biocLite on the Mac.
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
email: [EMAIL PROTECTED]
tel: 604-675-8000 x7561
BCCRC
Molecular Oncology
675 West 10th Ave, Floor 4
Vancouver B.C.
V5Z 1L3
Canada
-Original Message-
From: Herve Pages [mailto:[EMAIL PROTECTED]
Sent: Tue 7/18/2006 12:51 PM
To: Steven McKinney
Cc: [EMAIL PROTECTED]
Subject: Re: [BioC] Errors using biocLite on Apple OS X
Hi Steven,
I can see warnings only in what you reported. These warnings
are well-known issues but are not biocLite problems: they are
Mac OS X install.packages() specific issues.
The first warning:
1: number of rows of result
is not a multiple of vector length (arg 2) in: cbind(1, res0,
Repository = repos)
is issued by install.packages() when it is given a repos vector with
length >= 4.
You can easily reproduce it with:
> repos <- c("http://bioconductor.org/packages/1.8/bioc";,
"http://bioconductor.org/packages/1.8/data/annotation";,
"http://bioconductor.org/packages/1.8/data/experiment";,
"http://bioconductor.org/packages/1.8/omegahat";,
"http://bioconductor.org/packages/1.8/lindsey";,
"http://cran.fhcrc.org";)
> install.packages("Biobase", repos=repos)
The second warning is a permission issue specific to Mac OS X.
Anyway, these warnings should not prevent biocLite to install the requested
packages correctly.
Cheers,
H.
Steven McKinney wrote:
> I've recently started using R and Bioconductor
> on an Apple Mac running OS X (10.4). I've been
> installing packages from the *nix command line,
> one by one, no trouble.
>
> I would like to be able to update using
> biocLite from the R gui, but keep getting
> errors.
>
>
>> version
> _
> platform powerpc-apple-darwin8.6.0
> arch powerpc
> os darwin8.6.0
> system powerpc, darwin8.6.0
> status
> major 2
> mi
