[Rd] pcalg: labels
I never got a response from pcalg's maintainer, so I thought I'd
publisher a patch here that allows you to specify optional
node-labels; when no labels are specified, `plot' falls back on the
default behaviour of labelling nodes sequentially.
diff -Naur pcalg-orig/R/pcalg.R pcalg/R/pcalg.R
--- pcalg-orig/R/pcalg.R2007-03-22 03:20:49.0 -0700
+++ pcalg/R/pcalg.R 2007-11-26 00:07:24.0 -0800
@@ -292,14 +292,25 @@
})
setMethod("plot", signature(x = "pcAlgo"),
- function(x, y, main = NULL, zvalue.lwd = FALSE, lwd.max = 7, ...)
+ function(x, y, main = NULL, zvalue.lwd = FALSE, lwd.max = 7,
+ labels = NULL, ...)
{
if(is.null(main))
main <- deparse([EMAIL PROTECTED])
+attrs <- list()
+nodeAttrs <- list()
+if (!is.null(labels)) {
+ attrs$node <- list(shape = "ellipse", fixedsize = FALSE)
+ names(labels) <- nodes([EMAIL PROTECTED])
+ nodeAttrs$label <- labels
+}
if (zvalue.lwd & numEdges([EMAIL PROTECTED])!=0) {
lwd.Matrix <- [EMAIL PROTECTED]
lwd.Matrix <- ceiling(lwd.max*lwd.Matrix/max(lwd.Matrix))
- z <- agopen([EMAIL PROTECTED],name="lwdGraph")
+ z <- agopen([EMAIL PROTECTED],
+ name="lwdGraph",
+ nodeAttrs = nodeAttrs,
+ attrs = attrs)
eLength <- length([EMAIL PROTECTED])
for (i in 1:eLength) {
x <- as.numeric([EMAIL PROTECTED]@head)
@@ -308,7 +319,8 @@
}
plot(z, main = main, ...)
} else {
- plot([EMAIL PROTECTED], main = main, ...)
+ plot([EMAIL PROTECTED], nodeAttrs = nodeAttrs, main = main,
+ attrs = attrs, ...)
}
})
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with configure's detection of glob on 2.6.0 (PR#10468)
Full_Name: Mike Pacey Version: 2.6.0 OS: SuSe Linux 9.3 x86_64 Submission from: (NULL) (194.80.32.10) A "vanilla" version of R configures and compiles without a problem on my system. Switching to using the PGI compiler configures correctly (see the values at the bottom fo thismessage), but compilation aborts with: pgcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee -c platform.c -o platform.o PGC-S-0040-Illegal use of symbol, glob_t (platform.c: 1141) PGC-W-0156-Type not specified, 'int' assumed (platform.c: 1141) PGC-W-0095-Type cast required for this conversion (platform.c: 1168) PGC/x86-64 Linux 7.0-2: compilation completed with severe errors make[3]: *** [platform.o] Error 2 Running a diff on ./src/include/config.h files from both installs highlights a difference in the #define settings. For the vanilla install I get: /* Define to 1 if you have the `glob' function. */ #define HAVE_GLOB 1 /* Define to 1 if you have the header file. */ #define HAVE_GLOB_H 1 For the PGI version of the install I get: /* Define to 1 if you have the `glob' function. */ /* #undef HAVE_GLOB */ /* Define to 1 if you have the header file. */ #define HAVE_GLOB_H 1 I was a little puzzled as to why the latter would have the glob header file but not glob itself, so I modified the config.h file so that HAVE_GLOB was #defined to 1. The result compiles and passes the "make check" tests. Have I missed something or is configure/autoconf doing something odd with glob detection? - Flags/variables for the PGI install are: export CC=pgcc export CFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" export F77=pgf77 export FFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" export CXX=pgCC export CXXFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" export FC=pgf95 export FCFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" export SHLIB_CXXLDFLAGS=-shared export SHLIB_LDFLAGS=-shared ./configure --prefix=/usr/local/packages/R-2.6.0-acml \ --with-blas="-lacml" --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib64 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with configure's detection of glob on 2.6.0 (PR#10468)
I've no idea about the glob detection, but clearly this is the first system that allegedly lacks glob that we have encountered: the file needs to be #if defined(HAVE_GLOB) || defined(Win32) glob_t globbuf; #endif Have fixed that for 2.6.1 patched. On Mon, 26 Nov 2007, [EMAIL PROTECTED] wrote: > Full_Name: Mike Pacey > Version: 2.6.0 > OS: SuSe Linux 9.3 x86_64 > Submission from: (NULL) (194.80.32.10) > > > > A "vanilla" version of R configures and compiles without a problem on my > system. > Switching to using the PGI compiler configures correctly (see the values at > the > bottom fo thismessage), but compilation aborts with: > > pgcc -I../../src/extra/zlib -I../../src/extra/bzip2 -I../../src/extra/pcre > -I. > -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H > -Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee -c platform.c -o platform.o > PGC-S-0040-Illegal use of symbol, glob_t (platform.c: 1141) > PGC-W-0156-Type not specified, 'int' assumed (platform.c: 1141) > PGC-W-0095-Type cast required for this conversion (platform.c: 1168) > PGC/x86-64 Linux 7.0-2: compilation completed with severe errors > make[3]: *** [platform.o] Error 2 > > > Running a diff on ./src/include/config.h files from both installs highlights a > difference in the #define settings. For the vanilla install I get: > > /* Define to 1 if you have the `glob' function. */ > #define HAVE_GLOB 1 > > /* Define to 1 if you have the header file. */ > #define HAVE_GLOB_H 1 > > For the PGI version of the install I get: > > /* Define to 1 if you have the `glob' function. */ > /* #undef HAVE_GLOB */ > > /* Define to 1 if you have the header file. */ > #define HAVE_GLOB_H 1 > > I was a little puzzled as to why the latter would have the glob header file > but > not glob itself, so I modified the config.h file so that HAVE_GLOB was > #defined > to 1. The result compiles and passes the "make check" tests. > > Have I missed something or is configure/autoconf doing something odd with glob > detection? > > - > > Flags/variables for the PGI install are: > export CC=pgcc > export CFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" > export F77=pgf77 > export FFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" > export CXX=pgCC > export CXXFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" > export FC=pgf95 > export FCFLAGS="-Mvect=sse -Mscalarsse -Mcache_align -O2 -Kieee" > export SHLIB_CXXLDFLAGS=-shared > export SHLIB_LDFLAGS=-shared > ./configure --prefix=/usr/local/packages/R-2.6.0-acml \ > --with-blas="-lacml" --x-includes=/usr/X11R6/include > --x-libraries=/usr/X11R6/lib64 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Levy (PR#10469)
Full_Name: Vincent Remacle Version: 2.5.1 OS: Windows XP Submission from: (NULL) (81.246.37.50) > fit = vglm(x ~ 1, levy(idelta=2,igamma=2),trace=TRUE) Error: cannot allocate vector of size 30.5 Mb In addition: Warning messages: 1: NaNs produced in: log(x) 2: Reached total allocation of 1015Mb: see help(memory.size) in: colnames(qr$qr) <- colnames(x)[qr$pivot] 3: Reached total allocation of 1015Mb: see help(memory.size) in: colnames(qr$qr) <- colnames(x)[qr$pivot] 4: Reached total allocation of 1015Mb: see help(memory.size) in: colnames(qr$qr) <- colnames(x)[qr$pivot] 5: Reached total allocation of 1015Mb: see help(memory.size) in: colnames(qr$qr) <- colnames(x)[qr$pivot] > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] colnames slow (PR#10470)
Full_Name: Tomas Larsson Version: 2.6.0 OS: Windows XP Submission from: (NULL) (198.208.251.24) This is not a bug, it is a performance issue but I think it should have an easy fix. I have a large matrix (about 2,000,000 by 20), when I type colnames(x) it takes a long time to get the result. However, if I select just the first couple of rows of the matrix I don't have to wait for the result. See below for example. > system.time(colnames(x)) user system elapsed 9.980.00 10.00 > system.time(colnames(x[1:2,])) user system elapsed 0.010.000.02 Sincerely, Tomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] colnames slow (PR#10470)
[EMAIL PROTECTED] wrote: > Full_Name: Tomas Larsson > Version: 2.6.0 > OS: Windows XP > Submission from: (NULL) (198.208.251.24) > > > This is not a bug, it is a performance issue but I think it should have an > easy > fix. > > I have a large matrix (about 2,000,000 by 20), when I type colnames(x) it > takes > a long time to get the result. However, if I select just the first couple of > rows of the matrix I don't have to wait for the result. See below for example. > >> system.time(colnames(x)) >user system elapsed >9.980.00 10.00 >> system.time(colnames(x[1:2,])) >user system elapsed >0.010.000.02 Documentation in the released version of R (2.6.1) tells us: For a data frame, 'rownames' and 'colnames' are calls to 'row.names' and 'names' respectively, but the latter are preferred. and on my machine I get: system.time(names(x)) user system elapsed 0 0 0 Uwe Ligges > Sincerely, > > Tomas > > __ > 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] Levy (PR#10469)
[EMAIL PROTECTED] wrote: > Full_Name: Vincent Remacle > Version: 2.5.1 Please see the FAQs on how to report bugs. R-2.5.1 is two releases older than required. > OS: Windows XP > Submission from: (NULL) (81.246.37.50) > > >> fit = vglm(x ~ 1, levy(idelta=2,igamma=2),trace=TRUE) - What is x? We could not reproduce in case we need to. - vglm() is not a function that ships with R. Please tell us which contributed packages you are using (I am assuming VGAM). - Please note that bugs in contributed packages are to be reported to the package maintainers, not to R-bugs. > Error: cannot allocate vector of size 30.5 Mb > In addition: Warning messages: > 1: NaNs produced in: log(x) > 2: Reached total allocation of 1015Mb: see help(memory.size) in: > colnames(qr$qr) > <- colnames(x)[qr$pivot] > 3: Reached total allocation of 1015Mb: see help(memory.size) in: > colnames(qr$qr) > <- colnames(x)[qr$pivot] > 4: Reached total allocation of 1015Mb: see help(memory.size) in: > colnames(qr$qr) > <- colnames(x)[qr$pivot] > 5: Reached total allocation of 1015Mb: see help(memory.size) in: > colnames(qr$qr) > <- colnames(x)[qr$pivot] Why do you think that it is a bug in R (or a contributed packages) that you do not have the required amount of RAM in your machine? Uwe Ligges > __ > 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] Change in write.dcf() that breaks existing code
Hi,
When writing a DCF file one record at a time, the records used
to be separated by an empty line in R-2.5, but not in R-2.6:
x <- data.frame(aa=letters[1:3], ii=1:3)
With R-2.5:
> x <- data.frame(aa=letters[1:3], ii=1:3)
> for (i in seq_len(nrow(x))) write.dcf(x[i, ,drop=FALSE])
aa: a
ii: 1
aa: b
ii: 2
aa: c
ii: 3
With R-2.6:
> for (i in seq_len(nrow(x))) write.dcf(x[i, ,drop=FALSE])
aa: a
ii: 1
aa: b
ii: 2
aa: c
ii: 3
Unfortunately, because of this change, code that used to be OK
now produces broken DCF files.
To add to the frustration, nothing is mentioned in the man page
or in the NEWS file:
CHANGES IN R VERSION 2.6.0
o write.dcf() no longer writes NA fields (PR#9796), and works
correctly on empty descriptions.
Although it seems that it was a deliberate choice. Found in base/R/dcf.R:
...
if(length(eor)) {
## Newline for end of record.
## Note that we do not write a trailing blank line.
eor[ diff(c(col(out))[is_not_empty]) >= 1 ] <- "\n"
}
...
What's the benefit of this change?
Cheers,
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
