Re: [Rd] dput/dget when a data frame has 2 rows (PR#9627)
It is right.
The problem is that dput() does not give a faithful representation, as its
help says. R 2.5.0 does a better job, since the defaults for dput() have
been changed, enough so that your example works there.
On Sun, 22 Apr 2007, [EMAIL PROTECTED] wrote:
> This doesn't seem right; I'm using R version 2.4.1 (2006-12-18) on Mac OS
> and Win XP and find the same issue:
>
>> mydataframe <- data.frame(ppi=c(.5,.5),mmu=c(5,10))
>> dput(mydataframe,"mydataframe.txt")
>> dget("mydataframe.txt")
> Error in attributes(.Data) <- c(attributes(.Data), attrib) :
>row names must be 'character' or 'integer', not 'double'
>> mydataframe3 <- data.frame(ppi=c(.5,.5,.5),mmu=c(5,10,15))
>> dput(mydataframe3,"mydataframe3.txt")
>> dget("mydataframe3.txt")
> ppi mmu
> 1 0.5 5
> 2 0.5 10
> 3 0.5 15
>
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to debug C code running in R
You haven't told us your OS (as asked for in the posting guide). But Writing R Extensions section 4.4 rw-FAQ Q8.4 both appear to give the instructions you are asking for. On Sun, 22 Apr 2007, Tong Wang wrote: > Hi, >I am in the situation where I could get my code run correctly under > GNU C, but it produced different (strange) results while running in R . > ( I use .C to call the function). May I get some general advice on how > could I do step by step debug of source code in R ? > > Thanks -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dendrogram definition
> On Fri, 20 Apr 2007 14:46:33 -0700, > Deepayan Sarkar (DS) wrote: > Hi, > I'm trying to create a "grob" representing a dendrogram object (for > use as a legend with lattice), and I have a question regarding how a > "dendrogram" should be interpreted. Are they by definition binary > trees or can they in principle have more than two children? They can have more than 2 children, and class "dendrogram" supports this. However, as most trees are currently created using hclust, all examples have binary trees. E.g., example(dendrogram) d3e[[3]]=d3e attr(d3e,"members")=14 str(d3e) creates a tree with three branches in the root node (not all attributes are correct after that brute force operation, so plots will not look as nice as possible). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to debug C code running in R
On 4/23/2007 12:21 AM, Tong Wang wrote: > Hi, > I am in the situation where I could get my code run correctly under GNU > C, but it produced different (strange) results > while running in R . ( I use .C to call the function). May I get some > general advice on how could I do step by step debug > of source code in R ? There's a chapter on debugging in Writing R Extensions, with specific advice for compiled code. I also put together a web page of mostly Windows-specific advice, at http://www.stats.uwo.ca/faculty/murdoch/software/debuggingR Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R RC: make all
Looks like make all does not imply make recommended in the RC version of R-2.5.0 ... Uwe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R RC: make all
Uwe Ligges wrote: > Looks like >make all > does not imply >make recommended > in the RC version of R-2.5.0 ... > > Uwe > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Eh? What makes you say that? all: Makefile Makeconf R docs recommended recommended: @USE_RECOMMENDED_PACKAGES_TRUE@ stamp-recommended -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R RC: make all
On Mon, 23 Apr 2007, Uwe Ligges wrote: > Looks like > make all > does not imply > make recommended > in the RC version of R-2.5.0 ... It never did on Windows, seems still to on Unix (I've just tested it under our Intel compilers, newly updated so they work again on Fedora Core 5). Brian -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R RC: make all
Peter Dalgaard wrote: > Uwe Ligges wrote: >> Looks like >>make all >> does not imply >>make recommended >> in the RC version of R-2.5.0 ... >> >> Uwe >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > Eh? What makes you say that? Apologies! This happens if doing things too quickly. I was talking about ./src/gnuwin32/Makefile and just recognized that 'make recommended' was never part of 'make all', just of 'make distribution'. I was somehow mixing it with the Linux version, obviously. My autobuilder usually builds R for me, hence I am unused to do it manually. Uwe > > all: Makefile Makeconf R docs recommended > recommended: @USE_RECOMMENDED_PACKAGES_TRUE@ stamp-recommended __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R RC: make all
On 4/23/2007 8:51 AM, Peter Dalgaard wrote:
> Uwe Ligges wrote:
>> Looks like
>>make all
>> does not imply
>>make recommended
>> in the RC version of R-2.5.0 ...
>>
>> Uwe
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> Eh? What makes you say that?
>
>
> all: Makefile Makeconf R docs recommended
> recommended: @USE_RECOMMENDED_PACKAGES_TRUE@ stamp-recommended
This is true in the Windows src/gnuwin32/Makefile, but it's not new.
The only target that depends on "recommended" is "distribution", and it
does it by forcing "make recommended" every time, whether needed or not.
"make all" also misses "bitmapdll" (which I think has no equivalent in
Unix?), "manuals" (part of "docs" in Unix), and installer related targets.
It would probably be reasonable if "make all" were more consistent
across platforms, but "make recommended" is quite slow, so I'm not sure
I would like it to be in the default ("all" is the default target).
Another argument in favour of including "recommended" in the default is
that currently "make ; make check" fails in Windows, because some of the
checks depend on recommended packages.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R RC: make all
On Mon, 23 Apr 2007, Duncan Murdoch wrote:
> On 4/23/2007 8:51 AM, Peter Dalgaard wrote:
>> Uwe Ligges wrote:
>>> Looks like
>>>make all
>>> does not imply
>>>make recommended
>>> in the RC version of R-2.5.0 ...
>>>
>>> Uwe
>>>
>> Eh? What makes you say that?
>>
>>
>> all: Makefile Makeconf R docs recommended
>> recommended: @USE_RECOMMENDED_PACKAGES_TRUE@ stamp-recommended
>
> This is true in the Windows src/gnuwin32/Makefile, but it's not new.
> The only target that depends on "recommended" is "distribution", and it
> does it by forcing "make recommended" every time, whether needed or not.
>
> "make all" also misses "bitmapdll" (which I think has no equivalent in
> Unix?), "manuals" (part of "docs" in Unix), and installer related targets.
'make manuals' is equivalent to 'make pdf' on Unix.
> It would probably be reasonable if "make all" were more consistent
> across platforms, but "make recommended" is quite slow, so I'm not sure
> I would like it to be in the default ("all" is the default target).
This could be overcome by using timestamps, as on Unix. However, those do
not work entirely right on Unix, as they only check if the package sources
have been updated, and not that R has been changed in a way that needs the
package to be regnerated (e.g. the C headers have changed, or methods need
to be re-dumped). So I have been reluctant to change to a known flawed
system. (Originally the Windows toolkit was missing 'touch', which you
would need to do timestamps right.)
> Another argument in favour of including "recommended" in the default is
> that currently "make ; make check" fails in Windows, because some of the
> checks depend on recommended packages.
>
> Duncan Murdoch
--
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] plot.xy() with type="s" and huge data (PR#9629)
The following code snippet crashes R (under Windows and Linux) for both R-2.4.1 and R-2.5.0 RC as of yesterday: set.seed(1) H <- rnorm(40) temp <- rnorm(40) plot(H, temp, type='s') # (no, it was not my idea to do something like that!) I *guess* it is some overflow in plot.xy() which calls .Internal(plot.xy(xy, type, pch, lty, col, bg, cex, lwd, ...)) but I haven't investigated closely enough, submitting the bug report in case anybody can (and has time to) fix this before tomorrow. Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot.xy() with type="s" and huge data (PR#9629)
On Mon, 23 Apr 2007 [EMAIL PROTECTED] wrote: > The following code snippet crashes R (under Windows and Linux) for both > R-2.4.1 and R-2.5.0 RC as of yesterday: > >set.seed(1) >H <- rnorm(40) >temp <- rnorm(40) >plot(H, temp, type='s') ># (no, it was not my idea to do something like that!) > > > I *guess* it is some overflow in plot.xy() which calls >.Internal(plot.xy(xy, type, pch, lty, col, bg, cex, lwd, ...)) > but I haven't investigated closely enough, submitting the bug report in > case anybody can (and has time to) fix this before tomorrow. It happens right after 2 calls to alloca(), which probably ought to be changed to non-stack allocations. (On Linux there is a complaint about stack overflow and valgrind complains that someone changed the stack pointer.) type='S' also uses alloca(). Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot.xy() with type="s" and huge data (PR#9629)
On Mon, 23 Apr 2007, Bill Dunlap wrote: > On Mon, 23 Apr 2007 [EMAIL PROTECTED] wrote: > >> The following code snippet crashes R (under Windows and Linux) for both >> R-2.4.1 and R-2.5.0 RC as of yesterday: >> >>set.seed(1) >>H <- rnorm(40) >>temp <- rnorm(40) >>plot(H, temp, type='s') >># (no, it was not my idea to do something like that!) >> >> >> I *guess* it is some overflow in plot.xy() which calls >>.Internal(plot.xy(xy, type, pch, lty, col, bg, cex, lwd, ...)) >> but I haven't investigated closely enough, submitting the bug report in >> case anybody can (and has time to) fix this before tomorrow. > > It happens right after 2 calls to alloca(), which probably > ought to be changed to non-stack allocations. (On Linux there > is a complaint about stack overflow and valgrind complains > that someone changed the stack pointer.) type='S' also uses > alloca(). I think rather it should use alloca for moderate sizes (for speed), and something else for large ones. Or perhaps we should just not allow such usage (the graphics device is going to have indigestion: Windows GDI only copes with 1000 segments or so and we need to split up the call). Certainly not something to be fixed for 2.5.0, and pretty low priority. What we can do quickly is stick in a stack check, which will stop the crash. -- 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] foreign::read.ssd and long names (PR#9631)
Full_Name: Jeff Hallman Version: 2.4.1 OS: Linux Submission from: (NULL) (132.200.32.34) read.ssd() invokes PROC COPY to create an xport file, but PROC COPY has some annoying limitations that read.ssd() should deal with. The first is that PROC COPY doesn't work with member names (the sectionnames argument to read.ssd) longer than 8 characters. The second is that PROC COPY also fails if any of the columns in the dataset being copied are too long, unless you first set (in SAS) "option validvarname = v6;". I'm including here a rewritten read.ssd() that deals with these two issues. The sectionnames 8-character limitation is dealt with by creating symbolic links with shorter names. The problem with long column names is handled by adding SAS code to set "option validvarname = v6", which shortens column names that are too long while still keeping them unique within the dataset. A further enhancement might be to use PROC CONTENTS to retrieve the full-length column names and then assign them as the column names of the returned data.frames, but that seems to be more effort than its worth. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Correction to PR #9631 (PR#9632)
Full_Name: Jeff Hallman
Version: 2.4.1
OS: Linux
Submission from: (NULL) (132.200.32.34)
When I filed this a few minutes ago, I left off the rewritten read.ssd(). I've
included it at the end this time.
read.ssd() invokes PROC COPY to create an xport file, but PROC COPY has some
annoying limitations that read.ssd() should deal with. The first is that PROC
COPY doesn't work with member names (the sectionnames argument to read.ssd)
longer than 8 characters. The second is that PROC COPY also fails if any of
the
columns in the dataset being copied are too long, unless you first set (in SAS)
"option validvarname = v6;".
I'm including here a rewritten read.ssd() that deals with these two issues.
The
sectionnames 8-character limitation is dealt with by creating symbolic links
with shorter names. The problem with long column names is handled by adding
SAS
code to set "option validvarname = v6", which shortens column names that are
too
long while still keeping them unique within the dataset. A further enhancement
might be to use PROC CONTENTS to retrieve the full-length column names and then
assign them as the column names of the returned data.frames, but that seems to
be more effort than its worth.
read.ssd <- function(libname,
sectionnames,
tmpXport = tempfile(),
tmpProgLoc = tempfile(),
sascmd = "sas"){
tmpFiles <- tmpXport
on.exit(unlink(tmpFiles))
logGuess <- function(x){
expl <- strsplit(x, "")[[1]]
rex <- rev(expl)
br <- match("/", rex)[1]
if(is.na(br))
return(x)
return(paste(rev(rex[1:(br - 1)]), sep = "", collapse = ""))
}
fileExtension <- function(string){
n <- nchar(string)
chars <- substring(string, 1:n, 1:n)
lastDot <- n + 1 - match(".", rev(chars), nomatch = n + 1)
substring(string, lastDot + 1, n)
}
sn <- sectionnames
if(any(nchar(sn) > 8)){
oldDir <- libname
libname <- tempdir()
allFiles <- list.files(oldDir)
oldNames <- character(0)
for(i in 1:length(sn)){
fName <- grep(sn[i], allFiles, value = T)
if(length(fName) == 0) stop(paste("sectionname", sn[i], "not found"))
oldNames <- c(oldNames, fName)
}
sectionnames <- linkNames <- character(length(oldNames))
for(i in 1:length(oldNames)){
sectionnames[i] <- paste("sn", i, sep = "")
linkNames[i] <- paste(sectionnames[i],
fileExtension(oldNames[i]),
sep = ".")
oldPath <- file.path(oldDir, oldNames[i])
linkPath <- file.path(libname, linkNames[i])
file.symlink(oldPath, linkPath)
tmpFiles <- c(tmpFiles, linkPath)
}
}
st0 <- "option validvarname = v6;"
st1 <- paste("libname src2rd '", libname, "';\n", sep = "")
st2 <- paste("libname rd xport '", tmpXport, "';\n", sep = "")
st3 <- paste("proc copy in=src2rd out=rd;\n")
st4 <- paste("select", sectionnames, ";\n", sep = " ")
tmpProg <- paste(tmpProgLoc, ".sas", sep = "")
tmpProgLogBase <- logGuess(tmpProgLoc)
tmpProgLog <- paste(tmpProgLogBase, ".log", sep = "")
cat(st0, file = tmpProg)
cat(st1, file = tmpProg, append = TRUE)
cat(st2, file = tmpProg, append = TRUE)
cat(st3, file = tmpProg, append = TRUE)
cat(st4, file = tmpProg, append = TRUE)
if(.Platform$OS.type == "windows")
sascmd <- paste(shQuote(sascmd), "-sysin")
sasrun <- try(sysret <- system(paste(sascmd, tmpProg)))
if(!inherits(sasrun, "try-error") & sysret == 0){
unlink(tmpProg)
unlink(tmpProgLog)
if(length(sectionnames) == 1) return(foreign::read.xport(tmpXport))
else {
zz <- read.xport(tmpXport)
names(zz) <- sn
return(zz)
}
}
else {
cat("SAS failed. SAS program at", tmpProg, "\n")
if(.Platform$OS.type == "unix"){
cat("a log and other error products should be in the vicinity\n")
system(paste("ls -l ", tmpProgLog))
}
else {
cat("The log file will be ", paste(basename(tmpProgLoc),
".log", sep = ""), " in the current
directory\n",
sep = "")
}
warning("SAS return code was ", sysret)
return(NULL)
}
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dendrogram definition
On 4/23/07, Friedrich Leisch <[EMAIL PROTECTED]> wrote: > > On Fri, 20 Apr 2007 14:46:33 -0700, > > Deepayan Sarkar (DS) wrote: > > > Hi, > > I'm trying to create a "grob" representing a dendrogram object (for > > use as a legend with lattice), and I have a question regarding how a > > "dendrogram" should be interpreted. Are they by definition binary > > trees or can they in principle have more than two children? > > They can have more than 2 children, and class "dendrogram" supports > this. However, as most trees are currently created using hclust, all > examples have binary trees. Thanks, that's what my guess was since the help page doesn't say anything special about binary trees. My code should work in either case. In case anyone's interested, there's an example of a lattice/grid heatmap at http://dsarkar.fhcrc.org/R/heatmap/lattice-heatmap.pdf (the primary benefit for me is better control over aspect ratio). -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
