[Rd] Field initialization order bug?
I believe that I may have found a bug in R. The top code sample gives an error as shown. However, by simply switching which field is initialized first as in the bottom code sample, it works as expected. This gives an error: a <- NULL a[["field1"]] <- 1 a[["field2"]] <- matrix(c(2,1), 1) Error in a[["field2"]] <- matrix(c(2, 1), 1) : more elements supplied than there are to replace Yet, this works as expected: a <- NULL a[["field2"]] <- matrix(c(2,1), 1) a[["field1"]] <- 1 Daniel Wilhelm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error while fitting Partial Proportional Odds model using vglm
Dear R developers:
I am trying to fit a PPO model using vglm from the library VGAM, and get an
error while executing the code. Here is the data, code, and error:
Data: first row is the column names. a = age, and 1,2,3, 4 and 5 are
condition grades.
a 1 2 3 4 5
1 1 0 0 0 0
2 84 2 7 10 2
3 16 0 6 6 2
4 13 0 3 4 0
5 0 0 0 1 0
Library(VGAM)
rc13<-read.table("icg_rcPivot_group2.txt",header=F)
names(rc13)<-c("a","1","2","3","4","5")
ppo<-vglm(cbind(rc13[,2],rc13[,3],rc13[,4],rc13[,5],rc13[,6])~a,family =
cumulative(link = logit, parallel = F , reverse = F),na.action=na.pass,
data=rc13)
summary(ppo)
I get the following error:
Error in "[<-"(`*tmp*`, , index, value = c(1.13512932539841,
0.533057528200189, :
number of items to replace is not a multiple of replacement length
In addition: Warning messages:
1: NaNs produced in: log(x)
2: fitted values close to 0 or 1 in: tfun(mu = mu, y = y, w = w, res =
FALSE, eta = eta, extra)
3: 19 elements replaced by 1.819e-12 in: checkwz(wz, M = M, trace = trace,
wzeps = control$wzepsilon)
Ironically, it works ok with Proportional Odds (change parallel = T above),
but fails with PPO (parallel = F).
I will appreciate any help to fix this problem.
Thanks
Rizwan Younis
Grad Student
University of Waterloo
Waterloo, ON Canada
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error while fitting Partial Proportional Odds model using vglm
Instead of repeatedly posting this message to the R lists, please contact
the maintainer as the R posting guide asked you to do in the first
instance.
E.g. you have already sent
https://stat.ethz.ch/pipermail/r-help/2007-July/136488.html
https://stat.ethz.ch/pipermail/r-help/2007-July/136510.html
On Mon, 16 Jul 2007, Rizwan Younis wrote:
> Dear R developers:
>
> I am trying to fit a PPO model using vglm from the library VGAM, and get an
> error while executing the code. Here is the data, code, and error:
>
> Data: first row is the column names. a = age, and 1,2,3, 4 and 5 are
> condition grades.
>
> a 1 2 3 4 5
> 1 1 0 0 0 0
> 2 84 2 7 10 2
> 3 16 0 6 6 2
> 4 13 0 3 4 0
> 5 0 0 0 1 0
>
> Library(VGAM)
>
> rc13<-read.table("icg_rcPivot_group2.txt",header=F)
> names(rc13)<-c("a","1","2","3","4","5")
>
> ppo<-vglm(cbind(rc13[,2],rc13[,3],rc13[,4],rc13[,5],rc13[,6])~a,family =
> cumulative(link = logit, parallel = F , reverse = F),na.action=na.pass,
> data=rc13)
> summary(ppo)
>
> I get the following error:
>
> Error in "[<-"(`*tmp*`, , index, value = c(1.13512932539841,
> 0.533057528200189, :
> number of items to replace is not a multiple of replacement length
> In addition: Warning messages:
> 1: NaNs produced in: log(x)
> 2: fitted values close to 0 or 1 in: tfun(mu = mu, y = y, w = w, res =
> FALSE, eta = eta, extra)
> 3: 19 elements replaced by 1.819e-12 in: checkwz(wz, M = M, trace = trace,
> wzeps = control$wzepsilon)
>
>
> Ironically, it works ok with Proportional Odds (change parallel = T above),
> but fails with PPO (parallel = F).
>
> I will appreciate any help to fix this problem.
> Thanks
>
> Rizwan Younis
> Grad Student
> University of Waterloo
> Waterloo, ON Canada
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unable to build with working iconv support on Solaris9/x86
Hi Brian, Thanks for the advice, but I'm still confused! On 17/07/2007, at 4:04 PM, Professor Brian Ripley wrote: > Note that as the R-admin says, you need to use a better iconv than > that supplied with most commercial Unices, including Solaris. Yes, I read that and installed libiconv-1.11 locally before trying to build R. > - as a preload plugin > - by installing it with the libiconv prefix, and ensuring its iconv.h > is first in your path. I've read a number of articles explaining why LD_PRELOAD is considered harmful and should be avoided. I'm trying to be a good systems administrator and do things the "right" way. As I understand it RPATH (-R/somelocation argument to the linker) should take care of this problem (but clearly it doesn't in this case). When you say libiconv prefix, you're referring to '--with-libiconv- prefix=/somelocation' correct? And what do you mean by "ensuring iconv.h is first in your path"? If I provide CFLAGS="-I/ somelocation" that should be searched first for headers before the default system locations as I understand? But surely once the binary is built, the headers order doesn't matter? > If you have two libraries with the same entry point (iconv here) > which one gets resolved to is pretty arcane. Hence the need for > a prefix. Doesn't the output of 'ldd -s bin/exec/R' show the order in which locations are searched for DSOs and confirm that /usr/local/apps/ libiconv-1.11/lib/libiconv.so.2 is found first and used? You are correct though, 'LD_PRELOAD=/usr/local/apps/libiconv-1.11/lib/ libiconv.so make check' passes all tests up to d-p-q-r, whereas it would usually fail on the first. Regards, -- Lucas Barbuto E: [EMAIL PROTECTED] System AdministratorT: +613 8344 1270 Department of CSSE The University of Melbourne http://www.csse.unimelb.edu.au/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error while fitting Partial Proportional Odds model using vglm
On Mon, 2007-07-16 at 17:27 -0400, Rizwan Younis wrote: > Dear R developers: This is *not* the correct list for help with R or contributed packages on CRAN, and please do not send your messages repeatedly to any of the lists - this is at least the 3rd time I've received this request for help. If you'd read the posting guide, it would have told you that you should email the package maintainer (in this case Thomas Yee) for help with a contributed package. If you must email the R-help list, do so only once. If you don't get a reply, take the hint that perhaps no-one has an answer - repeatedly bugging them isn't going to help! By the looks of things, there is either a problem within VGAM itself that only Thomas will be able to fix, or you are providing an argument/data that VGAM was not expecting - there appear to be some fitting problems also. Check that the data you are providing are what VGAM expects, and if the problem still persists, email Thomas with a reproducible example. G -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [t] +44 (0)20 7679 0522 ECRC [f] +44 (0)20 7679 0565 UCL Department of Geography Pearson Building [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street London, UK[w] http://www.ucl.ac.uk/~ucfagls/ WC1E 6BT [w] http://www.freshwaters.org.uk/ %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Field initialization order bug?
Daniel Wilhelm wrote: > I believe that I may have found a bug in R. The top code sample gives > an error as shown. However, by simply switching which field is > initialized first as in the bottom code sample, it works as expected. > > > This gives an error: > > > a <- NULL > a[["field1"]] <- 1 > a[["field2"]] <- matrix(c(2,1), 1) > > Error in a[["field2"]] <- matrix(c(2, 1), 1) : > more elements supplied than there are to replace > > > > Yet, this works as expected: > > a <- NULL > a[["field2"]] <- matrix(c(2,1), 1) > a[["field1"]] <- 1 > I'm surprised any of these work. I didn't expect to be able to index NULL, but the clue is there in the man page for "[[": "the left-hand-side is coerced as needed to accept the values." What's happening is that in the first case, a becomes a numeric vector, and you can't assign a matrix to an element of a numeric vector. It won't fit. In the second case, a becomes a list, and the assignments both succeed. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Field initialization order bug?
On Mon, 16 Jul 2007, Daniel Wilhelm wrote:
> I believe that I may have found a bug in R. The top code sample gives
You have 'merely' found a bug in your understanding. What type did you
expect 'a' to be? If you expected a list, that is not what happens in the
first example, and you need
a <- list()
or, better,
a <- vector("list", 2)
> an error as shown. However, by simply switching which field is
> initialized first as in the bottom code sample, it works as expected.
>
>
> This gives an error:
>
>
> a <- NULL
> a[["field1"]] <- 1
Now a is numeric
> a[["field2"]] <- matrix(c(2,1), 1)
>
> Error in a[["field2"]] <- matrix(c(2, 1), 1) :
> more elements supplied than there are to replace
>
>
>
> Yet, this works as expected:
>
> a <- NULL
> a[["field2"]] <- matrix(c(2,1), 1)
Now a is a list
> a[["field1"]] <- 1
>
>
>
> Daniel Wilhelm
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R with Sun Studio Compiler
On Mon, 16 Jul 2007, Prof Brian Ripley wrote:
> The R-admin manual did tell you not to do that!
>
> When using the Sun compilers do @emph{not} specify @option{-fast}, as
> this disables @acronym{IEEE} arithmetic and @command{make check} will
> fail.
>
> That was for Solaris and SunStudio 11, but I presume these are basically the
> same compilers. (--fast has been a no-no for as long as I have been using R
> on Solaris, ca 10 years.)
There is another problem with -fast on x86 that is probably the cause of
your problem. It implies -nofstore, and we needed to force storage on
some Fortran routines under g77/gfortran to avoid an infinite loop.
However, even if you set SAFE_FFLAGS, the likely problems with IEC60559
compliance remain.
>
> On Mon, 16 Jul 2007, Len Zaifman wrote:
>
>> I would like to Build R-2.5.1 on OpenSUSE 10.2 using the SunStudio 12
>> compilers(http://developers.sun.com/sunstudio/index.jsp)
>>
>> R builds and passes make check fine without optimising. However, when I try
>> to compile with optimisation turned on
>> (-fast) the build gets stuck in an infinite loop at the following point:
>>
>> Sun_Studio/sunstudio12/bin/cc -m64 -shared -Kpic -m64 -fPIC -o
>> grDevices.so chull.o devNull.o devPicTeX.o devPS.o
>> devQuartz.o init.o
>> mkdir -p -- ../../../../library/grDevices/libs
>> make[5]: Leaving directory
>> `/export/home/leonardz/ccb/HPF/support/R-2.5.1/ss12/R-2.5.1/src/library/grDevices/src'
>> make[4]: Leaving directory
>> `/export/home/leonardz/ccb/HPF/support/R-2.5.1/ss12/R-2.5.1/src/library/grDevices/src'
>>
>> R is running at this point and will run for as long as I do not kill it. If
>> I compile without -fast the next line in the make is:
>>
>> make[3]: Entering directory
>> `/export/home/leonardz/ccb/HPF/support/R-2.5.1/ss12/R-2.5.1/src/library/graphics'
>>
>> and the entire package builds and make check verifies correctly. Any ideas
>> on why this is happening?
>>
>> The build works fine for gcc as well.
>>
>>
>
>
--
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] Field initialization order bug?
Prof Brian Ripley wrote:
> On Mon, 16 Jul 2007, Daniel Wilhelm wrote:
>
>
>> I believe that I may have found a bug in R. The top code sample gives
>>
>
> You have 'merely' found a bug in your understanding. What type did you
> expect 'a' to be? If you expected a list, that is not what happens in the
> first example, and you need
>
> a <- list()
>
> or, better,
>
> a <- vector("list", 2)
>
>
To be precise, you need
a <- vector("list", 2) ; names(a) <- c("field1", "field2")
or you end up with a 4-element list.
--
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] S4 coerce
Seth Falcon wrote:
>Paul Gilbert <[EMAIL PROTECTED]> writes:
>
>
>
>>(I am not sure if this is a bug or a request for a more understandable
>>warning, or possible something obvious I should be posting on r-help.)
>>
>>I am trying to coerce an new class object to be a DBIConnection and it
>>does not work the way I think it should:
>>
>>R version 2.5.1 (2007-06-27) ...
>> > require("RMySQL") # or require("RSQLite")
>>Loading required package: RMySQL
>>Loading required package: DBI
>>[1] TRUE
>> > m <- dbDriver("MySQL") # or m <- dbDriver("SQLite")
>> > con <- dbConnect(m, dbname="test")
>> > dbGetQuery(con, "create table zzz (
>>+vintage VARCHAR(20) NOT NULL,
>>+alias VARCHAR(20) default NULL,
>>+Documentation TEXT,
>>+PRIMARY KEY (vintage)
>>+);")
>>NULL
>> > dbListTables(con)
>> [1] "zzz"
>> > setClass("TSconnection", representation(con="DBIConnection",
>>+vintage = "logical",
>>+panel = "logical")
>>+)
>>[1] "TSconnection"
>> > setAs("TSconnection", "DBIConnection", def = function(from) [EMAIL
>> > PROTECTED])
>>
>>
>
>I think things work as you expect up until this pint.
>
>
Yes.
>
>
>> > setIs("TSconnection", "DBIConnection", coerce = function(x)
>> > [EMAIL PROTECTED])
>>
>>
>
>I'm confused about what you want to do here. If you want TSconnection
>to be a DBIConnection, why wouldn't you use inheritance?
>
> setClass("TSconnection", contains="DBIConnection", ...)
>
>
Perhaps my logic is confused, it wouldn't be the first time, but I am
thinking of this as going the "other direction" from inheritance. A
MySQLConnection or SQLiteConnection inherits from DBIConnection. To
actually use a DBIConnection or my TSconnection it will be necessary to
have one of these, so I would need something like
setClass("TSconnection", contains="MySQLConnection", ...)
to make this work. (Actually, I have not been able to make it work, but
that may just be the novice level of my experimenting.) I am hoping I
can define the TSconnection using only DBIConnection classes and have it
automatically work when one of the database driver packages is added.
Otherwise I have to define the TSconnection for each of the driver
packages, which is not as clean.
Paul
>+ seth
>
>
>
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formula(CO2)
About a month ago I had a similar issue related to 'formula': http://tolstoy.newcastle.edu.au/R/e2/devel/07/05/3329.html In summary: In S-Plus, the help for formula.data.frame says: This is a method for the function formula() for objects inheriting from class data.frame. If object is a model frame, the formula for the model frame is returned, otherwise a formula is deduced from the names of object. The first name is taken to be the response, and all the remaining names are pasted together additively. In R, the help for formula.data.frame is aliased to the help for formula, but does not clearly document the usage with data.frames. Kevin On 7/16/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > The formula attribute of the builtin CO2 dataset seems a bit strange: > > > formula(CO2) > Plant ~ Type + Treatment + conc + uptake > > What is one supposed to do with that? Certainly its not suitable for > input to lm and none of the examples in ?CO2 use the above. > > __ > 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] substitute and expression
Deepayan Sarkar wrote:
> On 7/16/07, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>
>> Deepayan Sarkar wrote:
>>
>>> Hi,
>>>
>>> I'm trying to understand whether the use of substitute() is
>>> appropriate/documented for plotmath annotation. The following two
>>> calls give the same results:
>>>
>>>
>>>
plot(1:10, main = expression(alpha == 1))
do.call(plot, list(1:10, main = expression(alpha == 1)))
>>> But not these two:
>>>
>>>
>>>
plot(1:10, main = substitute(alpha == a, list(a = 2)))
do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
>>> Error in as.graphicsAnnot(main) : object "alpha" not found
>>>
>>> (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
>>> currently work.)
>>>
>>> On the other hand, this works:
>>>
>>>
>>>
foo <- function(x) plot(1, main = x)
foo(substitute(alpha))
>>> I'm not sure how to interpret ?plotmath; it says
>>>
>>> If the 'text' argument to one of the text-drawing functions
>>> ('text', 'mtext', 'axis', 'legend') in R is an expression, the
>>> argument is interpreted as a mathematical expression...
>>>
>>> and uses substitute() in its examples, but
>>>
>>>
>>>
is.expression(substitute(alpha == a, list(a = 1)))
>>> [1] FALSE
>>>
>>>
>> I think you need to take plotmath out of the equation and study the
>> difference between objects of mode "call" and those of mode
>> "expression". Consider this:
>>
>> > f <- function(...)match.call()
>> > do.call(f, list(1:10, main = substitute(alpha == a, list(a = 2
>> function(...)match.call()
>> (1:10, main = alpha == 2)
>> > do.call(list, list(1:10, main = substitute(alpha == a, list(a = 2
>> Error in do.call(list, list(1:10, main = substitute(alpha == a, list(a =
>> 2 :
>> object "alpha" not found
>>
>> The issue is that function ends up with an argument alpha == 2 which it
>> proceeds to evaluate (lazily), where a direct call sees
>> substitute(.). It is a general problem with the do.call mechanism
>> that it effectively pre-evaluates the argument list, which can confuse
>> functions that rely on accessing the original argument expression. Try,
>> e.g., do.call(plot, list(airquality$Wind, airquality$Ozone)) and watch
>> the axis labels.
>>
>
> Right. Lazy evaluation was the piece I was missing.
>
>
>> Does it work if you use something like
>>
>> main = substitute(quote(alpha == a), list(a = 2))?
>>
>
> Not for xyplot, though I haven't figured out why. Turns out this also
> doesn't work:
>
>
>> plot(y ~ x, data = list(x = 1:10, y = 1:10), main = substitute(alpha))
>>
> Error in as.graphicsAnnot(main) : object "alpha" not found
>
> I'll take this to mean that the fact that substitute() works sometimes
> (for plotmath) is an undocumented side effect of the implementation
> that should not be relied upon.
>
Probably the correct solution is to use expression objects. More or less
the entire reason for their existence is this sort of surprises.
plot(y ~ x, data = list(x = 1:10, y = 1:10), main =
as.expression(substitute(alpha==a, list(a=2
I'm not going to investigate why this is necessary in connection with
plot(), but the core issue is probably
> e <- quote(f(x)) ; e[[2]] <- quote(2+2)
> e
f(2 + 2)
> f <- quote(f(2+2))
> identical(e,f)
[1] TRUE
notice that since the two calls are identical, there is no way for e to
detect that it was called with x replaced by an object of mode "call".
Or put differently, objects of mode call tend to lose their
"personality" in connection with computing on the language.
--
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
[Rd] write.dcf/read.dcf cycle converts missing entry to "NA" (PR#9796)
Full_Name: Bill Dunlap
Version: 2.5.0
OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 6)
Submission from: (NULL) (24.17.60.30)
If you read a dcf file with read.dcf(file,fields=c("Field",...))
and the file does not contain the desired field "Field",
read.dcf puts a character NA for that entry in its output
matrix. If you then call write.dcf, passing it the output
of read.dcf(), it will write the entry "Field: NA". A subsequent
read.dcf() on write.dcf's output file will then have a "NA",
not a character NA, in the entry for "Field". I think that
write.dcf() should not write lines in the output file where
the input matrix contains a character NA.
Here is a test function to demonstrate the problem. It returns
TRUE when a write.dcf/read.dcf cycle does not change the data.
test.write.dcf <- function () {
origFile <- tempfile()
copyFile <- tempfile()
on.exit(unlink(c(origFile, copyFile)))
writeLines(c("Package: testA", "Version: 0.1-1", "Depends:", "",
"Package: testB", "Version: 2.1" , "Suggests: testA", "",
"Package: testC", "Version: 1.3.1", ""),
origFile)
orig <- read.dcf(origFile,
fields=c("Package","Version","Depends","Suggests"))
write.dcf(orig, copyFile, width = 72)
copy <- read.dcf(copyFile,
fields=c("Package","Version","Depends","Suggests"))
value <- all.equal(orig, copy)
if (!identical(value, TRUE)) {
attr(value, "orig") <- orig
attr(value, "copy") <- copy
}
value
}
Currently we get
> test.write.dcf()
[1] "'is.NA' value mismatch: 0 in current 4 in target"
attr(,"orig")
Package Version Depends Suggests
[1,] "testA" "0.1-1" "" NA
[2,] "testB" "2.1" NA "testA"
[3,] "testC" "1.3.1" NA NA
attr(,"copy")
Package Version Depends Suggests
[1,] "testA" "0.1-1" "" "NA"
[2,] "testB" "2.1" "NA""testA"
[3,] "testC" "1.3.1" "NA""NA"
With the attached write.dcf() it returns TRUE.
The diff would be
19,22c19,24
< eor <- character(nr * nc)
< eor[seq.int(1, nr - 1) * nc] <- "\n"
< writeLines(paste(formatDL(rep.int(colnames(x), nr), c(t(x)),
< style = "list", width = width, indent = indent), eor,
---
> tx <- t(x)
> not.na <- c(!is.na(tx))
> eor <- character(sum(not.na))
> eor[ c(diff(c(col(tx))[not.na]),0)==1 ] <- "\n"
> writeLines(paste(formatDL(rep.int(colnames(x), nr), c(tx),
> style = "list", width = width, indent = indent)[not.na], eor,
and the entire function would be
`write.dcf` <-
function (x, file = "", append = FALSE, indent = 0.1 * getOption("width"),
width = 0.9 * getOption("width"))
{
if (!is.data.frame(x))
x <- data.frame(x)
x <- as.matrix(x)
mode(x) <- "character"
if (file == "")
file <- stdout()
else if (is.character(file)) {
file <- file(file, ifelse(append, "a", "w"))
on.exit(close(file))
}
if (!inherits(file, "connection"))
stop("'file' must be a character string or connection")
nr <- nrow(x)
nc <- ncol(x)
tx <- t(x)
not.na <- c(!is.na(tx))
eor <- character(sum(not.na))
eor[ c(diff(c(col(tx))[not.na]),0)==1 ] <- "\n"
writeLines(paste(formatDL(rep.int(colnames(x), nr), c(tx),
style = "list", width = width, indent = indent)[not.na], eor,
sep = ""), file)
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Field initialization order bug?
PD> Prof Brian Ripley wrote:
PBR> On Mon, 16 Jul 2007, Daniel Wilhelm wrote:
>>> I believe that I may have found a bug in R. The top code sample
gives
PBR> You have 'merely' found a bug in your understanding.
PBR> What type did you expect 'a' to be? If you expected
PBR> a list, that is not what happens in the first
PBR> example, and you need
PBR> a <- list()
PBR>
PBR> or, better,
PBR>
PBR> a <- vector("list", 2)
PD> To be precise, you need
PD> a <- vector("list", 2) ; names(a) <- c("field1", "field2")
PD> or you end up with a 4-element list.
yes; and consequently, a more readable solution would start saying
a <- list(field1 = NULL, field2 = NULL)
or equivalently (and maybe nicer looking):
a <- list(field1 = {}, field2 = {})
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem building R with Sun Studio Compiler
Thanks for all the replies:
Dr. Ripley gets it right:
I want -fast which turns on nofstore which caused the infinite loop and also
pointed out non-IEEE arithmetic.
On SUSE 10.2 I used -fast -fstore -fsimple=1 which fixed both problems and
still optimised:
make check passed and I get for gcc4.1 vs SunStudio 12:
186 vs 149 seconds, with all tests passed in both cases.
Prof Brian Ripley said:
> On Mon, 16 Jul 2007, Prof Brian Ripley wrote:
>
>> The R-admin manual did tell you not to do that!
>>
>> When using the Sun compilers do @emph{not} specify @option{-fast}, as
>> this disables @acronym{IEEE} arithmetic and @command{make check} will
>> fail.
>>
>> That was for Solaris and SunStudio 11, but I presume these are basically the
>> same compilers. (--fast has been a no-no for as long as I have been using R
>> on Solaris, ca 10 years.)
>
> There is another problem with -fast on x86 that is probably the cause of
> your problem. It implies -nofstore, and we needed to force storage on
> some Fortran routines under g77/gfortran to avoid an infinite loop.
>
> However, even if you set SAFE_FFLAGS, the likely problems with IEC60559
> compliance remain.
>
>>
>> On Mon, 16 Jul 2007, Len Zaifman wrote:
>>
>>> I would like to Build R-2.5.1 on OpenSUSE 10.2 using the SunStudio 12
>>> compilers(http://developers.sun.com/sunstudio/index.jsp)
>>>
>>> R builds and passes make check fine without optimising. However, when I try
>>> to compile with optimisation turned on
>>> (-fast) the build gets stuck in an infinite loop at the following point:
>>>
>>> Sun_Studio/sunstudio12/bin/cc -m64 -shared -Kpic -m64 -fPIC -o
>>> grDevices.so chull.o devNull.o devPicTeX.o devPS.o
>>> devQuartz.o init.o
>>> mkdir -p -- ../../../../library/grDevices/libs
>>> make[5]: Leaving directory
>>> `/export/home/leonardz/ccb/HPF/support/R-2.5.1/ss12/R-2.5.1/src/library/grDevices/src'
>>> make[4]: Leaving directory
>>> `/export/home/leonardz/ccb/HPF/support/R-2.5.1/ss12/R-2.5.1/src/library/grDevices/src'
>>>
>>> R is running at this point and will run for as long as I do not kill it. If
>>> I compile without -fast the next line in the make is:
>>>
>>> make[3]: Entering directory
>>> `/export/home/leonardz/ccb/HPF/support/R-2.5.1/ss12/R-2.5.1/src/library/graphics'
>>>
>>> and the entire package builds and make check verifies correctly. Any ideas
>>> on why this is happening?
>>>
>>> The build works fine for gcc as well.
>>>
>>>
>>
>>
>
> --
> 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
>
--
Len Zaifman
Systems Manager, Supercomputing Systems
Centre for Computational Biology
Hospital for Sick Children
Toronto, Ont. M5G 1X8
[EMAIL PROTECTED]
(416)813-5513
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem building R with Sun Studio Compiler on SLES 9 SP3
In a previous thread I had problems on openSuse 10.2 building R with
optimisation and discovered that if I wanted
optimisation I need to turn on
-fstore -fsimple1 (the first is to force storage on some Fortran routines , the
second is to ensure IEEE arithmetic,
with some optimisation).
That worked for my desktop. The real problem is to work on our servers
(Opterons running SLES9SP3)
Make works fine but make check fails in
base-Ex.R on IO, specifically from base-Ex.Rout.fail:
>
> if(capabilities("fifo")) {
+ zz <- fifo("foo", "w+")
+ writeLines("abc", zz)
+ print(readLines(zz))
+ close(zz)
+ unlink("foo")
+ }
Warning in fifo("foo", "w+") : cannot create fifo 'foo', reason 'Input/output
error'
Error in fifo("foo", "w+") : unable to open connection
Execution halted
Does anybody know what I need to do to get this fifo capability turned on?
--
Len Zaifman
Systems Manager, Supercomputing Systems
Centre for Computational Biology
Hospital for Sick Children
Toronto, Ont. M5G 1X8
[EMAIL PROTECTED]
(416)813-5513
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Field initialization order bug?
Thank you all for clarifying that bug in my understanding! I suppose
that I expected 'a' to be promoted to a list when indexed from NULL.
I will be more judicious in the future when I post.
Daniel Wilhelm
>On Mon, 16 Jul 2007, Daniel Wilhelm wrote:
>
>>I believe that I may have found a bug in R. The top code sample gives
>
>You have 'merely' found a bug in your understanding. What type did
>you expect 'a' to be? If you expected a list, that is not what
>happens in the first example, and you need
>
>a <- list()
>
>or, better,
>
>a <- vector("list", 2)
>
>>an error as shown. However, by simply switching which field is
>>initialized first as in the bottom code sample, it works as expected.
>>
>>
>>This gives an error:
>>
>>
>>a <- NULL
>>a[["field1"]] <- 1
>
>Now a is numeric
>
>>a[["field2"]] <- matrix(c(2,1), 1)
>>
>>Error in a[["field2"]] <- matrix(c(2, 1), 1) :
>> more elements supplied than there are to replace
>>
>>
>>
>>Yet, this works as expected:
>>
>>a <- NULL
>>a[["field2"]] <- matrix(c(2,1), 1)
>
>Now a is a list
>
>>a[["field1"]] <- 1
>>
>>
>>
>>Daniel Wilhelm
>>
>>__
>>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
