[Rd] Field initialization order bug?

2007-07-17 Thread Daniel Wilhelm
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

2007-07-17 Thread Rizwan Younis
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

2007-07-17 Thread Prof Brian Ripley
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

2007-07-17 Thread Lucas Barbuto
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

2007-07-17 Thread Gavin Simpson
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?

2007-07-17 Thread Duncan Murdoch
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?

2007-07-17 Thread Prof Brian Ripley
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

2007-07-17 Thread Prof Brian Ripley
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?

2007-07-17 Thread Peter Dalgaard
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

2007-07-17 Thread Paul Gilbert


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)

2007-07-17 Thread Kevin Wright
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

2007-07-17 Thread Peter Dalgaard
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)

2007-07-17 Thread bill
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?

2007-07-17 Thread Martin Maechler

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

2007-07-17 Thread Len Zaifman
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

2007-07-17 Thread Len Zaifman
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?

2007-07-17 Thread Daniel Wilhelm
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