Re: [Rd] R project testers - how to help out

[Prof Brian Ripley]

We have a 4-week alpha/beta/RC period every 6 months for testing 
before a 2.x.0 release.  This is announced here, and we get very 
little response.  I expect the testing window for R 2.13.0 to be 
Mar-Apr.


That said, we do quite extensive testing on the main platforms (ix86 
and x86_64 Linux, i386 and x64 Windows) and slightly less on ix86 Mac 
OS X, x86 Solaris and Sparc Solaris.  This includes very frequent 
automated runs over all available R packages.  And we do also make 
daily snapshots available for testing.


R itself comes with a quite extensive test suite, and tools for 
testing packages.  Some people have chosen to use particular 
unit-testing frameworks (such as package RUnits), but these are 
notorious for obfuscating problems to the extent that the public 
output from the check farms contains almost no clue as to the specific 
test failure.


I hope that is enough background for you to explore the status quo and 
come with specific proposals.  Thank you for your offer of help.


On Thu, 10 Feb 2011, James Goss wrote:



I just want to find out how I could help out with testing on the R 
project. I have many years of software development as well as QA and 
test of everything from chips to supercomputers and really enjoy 
testing.  Increasingly, I am working in data mining and large-scale 
statistical kinds of things and "R" is my tool of choice.


Any help is much appreciated.

James Goss
Los Angeles, CA

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Problem with confint function

[Kino Aguilar]

Hi,

I am currently doing logistic regression analyses and I am trying to get
confidence intervals for my partial logistic regression coefficients.
Supposing I am right in assuming that the formula to estimate a 95% CI for a
log odds coefficient is the following:

log odds - 1.96*SE to log odds + 1.96*SE

then I am not getting the right CI.

For instance, this is a summary of my model:
Estimate Std. Error z value Pr(>|z|)
(Intercept) -0.061060.29808  -0.205   0.8377
pSusSD   0.211840.36886   0.574   0.5658
pBenSD   1.202550.52271   2.301   0.0214 *
pBarSD  -0.086540.48749  -0.178   0.8591
pSevSD   0.997590.44795   2.227   0.0259 *

And this is are the corresponding CI when I call the confint function:
 2.5 %97.5 %
(Intercept) -0.6548023 0.5264357
pSusSD  -0.4980888 0.9733975
pBenSD   0.2665235 2.3495259
pBarSD  -1.0695945 0.8740359
pSevSD   0.1877044 1.9747499

Utilizing the formula I mentioned above, the correct CI for pSusSD would
actually be:
> .21184-1.96*.36886
[1] -0.5111256
> .21184+1.96*.36886
[1] 0.9348056

That is:
 2.5 %97.5 %
pSusSD  -0.5111256 0.9348056

I am wondering if there is a bug in the code or if there is another way to
calculate a 95% CI for a logistic regression coefficient that I am not aware
of?

Thanks!

-- 
All the best!,
~Joaquin A. Aguilar A. - aka Kino

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with confint function

[John Fox]

Dear Kino,

The confidence intervals that you've computed yourself are based on the Wald
statistic, while confint() computes confidence intervals based on the
likelihood-ratio statistic, by profiling the likelihood (see ?confint and
click on the link for confint.glm). Basing confidence intervals on the
likelihood is more computationally intensive but should be more accurate.

I hope this helps,
 John


John Fox
Senator William McMaster
  Professor of Social Statistics
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox




> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
> project.org] On Behalf Of Kino Aguilar
> Sent: February-11-11 1:26 PM
> To: R-devel@r-project.org
> Subject: [Rd] Problem with confint function
> 
> Hi,
> 
> I am currently doing logistic regression analyses and I am trying to get
> confidence intervals for my partial logistic regression coefficients.
> Supposing I am right in assuming that the formula to estimate a 95% CI
> for a log odds coefficient is the following:
> 
> log odds - 1.96*SE to log odds + 1.96*SE
> 
> then I am not getting the right CI.
> 
> For instance, this is a summary of my model:
> Estimate Std. Error z value Pr(>|z|)
> (Intercept) -0.061060.29808  -0.205   0.8377
> pSusSD   0.211840.36886   0.574   0.5658
> pBenSD   1.202550.52271   2.301   0.0214 *
> pBarSD  -0.086540.48749  -0.178   0.8591
> pSevSD   0.997590.44795   2.227   0.0259 *
> 
> And this is are the corresponding CI when I call the confint function:
>  2.5 %97.5 %
> (Intercept) -0.6548023 0.5264357
> pSusSD  -0.4980888 0.9733975
> pBenSD   0.2665235 2.3495259
> pBarSD  -1.0695945 0.8740359
> pSevSD   0.1877044 1.9747499
> 
> Utilizing the formula I mentioned above, the correct CI for pSusSD would
> actually be:
> > .21184-1.96*.36886
> [1] -0.5111256
> > .21184+1.96*.36886
> [1] 0.9348056
> 
> That is:
>  2.5 %97.5 %
> pSusSD  -0.5111256 0.9348056
> 
> I am wondering if there is a bug in the code or if there is another way
> to calculate a 95% CI for a logistic regression coefficient that I am
> not aware of?
> 
> Thanks!
> 
> --
> All the best!,
> ~Joaquin A. Aguilar A. - aka Kino
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with confint function

[peter dalgaard]

On Feb 11, 2011, at 19:25 , Kino Aguilar wrote:

> Hi,
> 
> I am currently doing logistic regression analyses and I am trying to get
> confidence intervals for my partial logistic regression coefficients.
> Supposing I am right in assuming that the formula to estimate a 95% CI for a
> log odds coefficient is the following:
> 
> log odds - 1.96*SE to log odds + 1.96*SE
> 
> then I am not getting the right CI.
> 
> For instance, this is a summary of my model:
>Estimate Std. Error z value Pr(>|z|)
> (Intercept) -0.061060.29808  -0.205   0.8377
> pSusSD   0.211840.36886   0.574   0.5658
> pBenSD   1.202550.52271   2.301   0.0214 *
> pBarSD  -0.086540.48749  -0.178   0.8591
> pSevSD   0.997590.44795   2.227   0.0259 *
> 
> And this is are the corresponding CI when I call the confint function:
> 2.5 %97.5 %
> (Intercept) -0.6548023 0.5264357
> pSusSD  -0.4980888 0.9733975
> pBenSD   0.2665235 2.3495259
> pBarSD  -1.0695945 0.8740359
> pSevSD   0.1877044 1.9747499
> 
> Utilizing the formula I mentioned above, the correct CI for pSusSD would
> actually be:
>> .21184-1.96*.36886
> [1] -0.5111256
>> .21184+1.96*.36886
> [1] 0.9348056
> 
> That is:
> 2.5 %97.5 %
> pSusSD  -0.5111256 0.9348056
> 
> I am wondering if there is a bug in the code or if there is another way to
> calculate a 95% CI for a logistic regression coefficient that I am not aware
> of?
> 

confint.glm computes using likelihood profiling (i.e., it inverts the 
likelihood ratio test criterion for a parameter). This is considered somewhat 
more accurate than the Wald approximation implied by +/- 1.96*SE. If you insist 
on the latter, try confint.default. (This *is* all on the help page for 
confint()!). 

> Thanks!
> 
> -- 
> All the best!,
> ~Joaquin A. Aguilar A. - aka Kino
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] read.csv trap

[Ben Bolker]

  Bump.

  It's been a week since I posted this to r-devel.  Any
thoughts/discussion?  Would R-core be irritated if I submitted a bug report?

  cheers
Ben


 Original Message 
Subject: read.csv trap
Date: Fri, 04 Feb 2011 11:16:36 -0500
From: Ben Bolker 
To: r-de...@stat.math.ethz.ch ,  David Earn


  This is not specifically a bug, but an (implicitly/obscurely)
documented behavior of read.csv (or read.table with fill=TRUE) that can
be quite dangerous/confusing for users.  I would love to hear some
discussion from other users and/or R-core about this ...  As always, I
apologize if I have missed some obvious workaround or reason that this
is actually the desired behavior ...

  In a nutshell, when fill=TRUE R guesses the number of columns from the
first 5 rows of the data set.  That's fine, and ?read.table documents this:

   The number of data columns is determined by looking at the first
 five lines of input (or the whole file if it has less than five
 lines), or from the length of ‘col.names’ if it is specified and
 is longer.  This could conceivably be wrong if ‘fill’ or
 ‘blank.lines.skip’ are true, so specify ‘col.names’ if necessary.

What is dangerous/confusing is that R silently **wraps** longer lines if
fill=TRUE (which is the default for read.csv).  I encountered this when
working with a colleague on a long, messy CSV file that had some phantom
extra fields in some rows, which then turned into empty lines in the
data frame.

  Here is an example and a workaround that runs count.fields on the
whole file to find the maximum column length and set col.names
accordingly.  (It assumes you don't already have a file named "test.csv"
in your working directory ...)

  I haven't dug in to try to write a patch for this -- I wanted to test
the waters and see what people thought first, and I realize that
read.table() is a very complicated piece of code that embodies a lot of
tradeoffs, so there could be lots of different approaches to trying to
mitigate this problem. I appreciate very much how hard it is to write a
robust and general function to read data files, but I also think it's
really important to minimize the number of traps in read.table(), which
will often be the first part of R that new users encounter ...

  A quick fix for this might be to allow the number of lines analyzed
for length to be settable by the user, or to allow a settable 'maxcols'
parameter, although those would only help in the case where the user
already knows there is a problem.

  cheers
Ben Bolker

===
writeLines(c("A,B,C,D",
 "1,a,b,c",
 "2,f,g,c",
 "3,a,i,j",
 "4,a,b,c",
 "5,d,e,f",
 "6,g,h,i,j,k,l,m,n"),
   con=file("test.csv"))


read.csv("test.csv")
try(read.csv("test.csv",fill=FALSE))

## assumes header=TRUE, fill=TRUE; should be a little more careful
##  with comment, quote arguments (possibly explicit)
## ... contains information about quote, comment.char, sep
Read.csv <- function(fn,sep=",",...) {
  colnames <- scan(fn,nlines=1,what="character",sep=sep,...)
  ncolnames <- length(colnames)
  maxcols <- max(count.fields(fn,sep=sep,...))
  if (maxcols>ncolnames) {
colnames <- c(colnames,paste("V",(ncolnames+1):maxcols,sep=""))
  }
  ## assumes you don't have any other columns labeled "V[large number]"
  read.csv(fn,...,col.names=colnames)
}

Read.csv("test.csv")

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] read.csv trap

[Ken.Williams]

On 2/11/11 1:39 PM, "Ben Bolker"  wrote:

>[snip]
> Original Message 
>Subject: read.csv trap
>Date: Fri, 04 Feb 2011 11:16:36 -0500
>From: Ben Bolker 
>To: r-de...@stat.math.ethz.ch ,  David Earn
>
>
>[snip]
>What is dangerous/confusing is that R silently **wraps** longer lines if
>fill=TRUE (which is the default for read.csv).
>[snip]


Based on your description, I would be very irritated if I encountered the
behavior you describe.  I would consider it a bug, though my opinion
doesn't necessarily count for much.

--
Ken Williams
Senior Research Scientist
Thomson Reuters
Phone: 651-848-7712
ken.willi...@thomsonreuters.com
http://labs.thomsonreuters.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] read.csv trap

[Laurent Gatto]

On 11 February 2011 19:39, Ben Bolker  wrote:
>
[snip]
>
> What is dangerous/confusing is that R silently **wraps** longer lines if
> fill=TRUE (which is the default for read.csv).  I encountered this when
> working with a colleague on a long, messy CSV file that had some phantom
> extra fields in some rows, which then turned into empty lines in the
> data frame.
>

As a matter of fact, this is exactly what happened to a colleague of
mine yesterday and caused her quite a bit of trouble. On the other
hand, it could also be considered as a 'bug' in the csv file. Although
no formal specification exist for the csv format, RFC 4180 [1]
indicates that 'each line should contain the same number of fields
throughout the file'.

[1] http://tools.ietf.org/html/rfc4180

Best wishes,

Laurent

>  Here is an example and a workaround that runs count.fields on the
> whole file to find the maximum column length and set col.names
> accordingly.  (It assumes you don't already have a file named "test.csv"
> in your working directory ...)
>
>  I haven't dug in to try to write a patch for this -- I wanted to test
> the waters and see what people thought first, and I realize that
> read.table() is a very complicated piece of code that embodies a lot of
> tradeoffs, so there could be lots of different approaches to trying to
> mitigate this problem. I appreciate very much how hard it is to write a
> robust and general function to read data files, but I also think it's
> really important to minimize the number of traps in read.table(), which
> will often be the first part of R that new users encounter ...
>
>  A quick fix for this might be to allow the number of lines analyzed
> for length to be settable by the user, or to allow a settable 'maxcols'
> parameter, although those would only help in the case where the user
> already knows there is a problem.
>
>  cheers
>    Ben Bolker
>
> ===
> writeLines(c("A,B,C,D",
>             "1,a,b,c",
>             "2,f,g,c",
>             "3,a,i,j",
>             "4,a,b,c",
>             "5,d,e,f",
>             "6,g,h,i,j,k,l,m,n"),
>           con=file("test.csv"))
>
>
> read.csv("test.csv")
> try(read.csv("test.csv",fill=FALSE))
>
> ## assumes header=TRUE, fill=TRUE; should be a little more careful
> ##  with comment, quote arguments (possibly explicit)
> ## ... contains information about quote, comment.char, sep
> Read.csv <- function(fn,sep=",",...) {
>  colnames <- scan(fn,nlines=1,what="character",sep=sep,...)
>  ncolnames <- length(colnames)
>  maxcols <- max(count.fields(fn,sep=sep,...))
>  if (maxcols>ncolnames) {
>    colnames <- c(colnames,paste("V",(ncolnames+1):maxcols,sep=""))
>  }
>  ## assumes you don't have any other columns labeled "V[large number]"
>  read.csv(fn,...,col.names=colnames)
> }
>
> Read.csv("test.csv")
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
[ Laurent Gatto | slashhome.be ]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Writting my own package - 64 bit problem with R_GetCCallable

[Ryan King]

Hello list,
I've been working on a package of my own.  It works fine on the 32bit
linux machines that I've tested it on.  Someone using 64bit ubuntu
wanted to try it, and surprising segfaults happened.  My test code
results in no segfault, errors, or leaks from my calls when run under
valgrind (I recompiled R with the level 2 valgrind instruments).  R
and packages are compiled from source, so this is hopefully not a
debian/ubuntu issue.  I'm totally stumped and hoping that this is a
silly / common 32 to 64 bit transition issue.

The problem seems to come when I attempt to access a function
registered by the Matrix package.  During compilation (on 64 bit only)
I get the ominous:

--
slim_stolen_from_matrix.c: In function ‘R_as_cholmod_sparse’:
slim_stolen_from_matrix.c:36: warning: implicit declaration of
function ‘R_GetCCallable’
slim_stolen_from_matrix.c:36: warning: cast to pointer from integer of
different size
--

The function in question is an identical copy of Matrix's
M_as_cholmod_sparse, reproduced below

--
CHM_SP
R_as_cholmod_sparse(CHM_SP ans, SEXP x, Rboolean check_Udiag, Rboolean
sort_in_place)
{
static CHM_SP(*fun)(CHM_SP,SEXP,Rboolean,Rboolean)= NULL;
if(fun == NULL)
fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
R_GetCCallable("Matrix", "as_cholmod_sparse");
return fun(ans, x, check_Udiag, sort_in_place);
}
--

I made this duplicate function since using Matrix's #include stubs
conflicts with my copy of the CHOLMOD library (I need some functions
Matrix doesn't make public).

When run, the code gives the following segfault when it reaches te
first call to that function:

--
Program received signal SIGSEGV, Segmentation fault.
0xf54314e2 in ?? ()
 *** caught segfault ***
address 0xf54314e2, cause 'memory not mapped'
--

As mentioned above, under valgrind the segault doesn't happen, but in
GDB, the function pointer can be seen to have some problem.  In 64 bit
--
35  fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
(gdb) p fun
$1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0
(gdb) n
37  return fun(ans, x, check_Udiag, sort_in_place);
(gdb) p fun
$2 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xf54314e2
--

vs 32bit
--
(gdb) p fun
$1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xb72a3ec0

--

I've never done 64 bit development, so I don't know what I've probably
done wrong.  I don't see an intermediate cast to an int to mess it up.
 Checking the pointer sizeof's seems like R_GetCCallable's return
should be the same size as the function pointer.

--
(gdb) p sizeof(void*)
$5 = 8
(gdb) p sizeof(CHM_SP*)
$6 = 8
(gdb) p sizeof(CHM_SP)
$7 = 8
(gdb) p sizeof(SEXP)
$8 = 8
(gdb) p sizeof(CHM_SP(*))
$9 = 8
(gdb) p sizeof(DL_FUNC)
$10 = 8
(gdb) p sizeof(DL_FUNC*)
$11 = 8
--

The function is invoked by
--
fitholder->Zt = R_as_cholmod_sparse
((CHM_SP)malloc(sizeof(cholmod_sparse)), Zt, TRUE, FALSE);
---

where Zt is a SEXP pointing to a Matrix-class sparse matrix passed by
.Call from R.  CHM_SP is a typedef'd pointer to a cholmod_sparse



> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=C  LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] emmpat_0.001   Matrix_0.999375-46 lattice_0.19-13

loaded via a namespace (and not attached):
[1] grid_2.12.1


Ryan King
University of Chicago
Dept. Health Studies

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Writting my own package - 64 bit problem with R_GetCCallable

[Simon Urbanek]

Ryan,

On Feb 11, 2011, at 4:29 PM, Ryan King wrote:

> Hello list,
> I've been working on a package of my own.  It works fine on the 32bit
> linux machines that I've tested it on.  Someone using 64bit ubuntu
> wanted to try it, and surprising segfaults happened.  My test code
> results in no segfault, errors, or leaks from my calls when run under
> valgrind (I recompiled R with the level 2 valgrind instruments).  R
> and packages are compiled from source, so this is hopefully not a
> debian/ubuntu issue.  I'm totally stumped and hoping that this is a
> silly / common 32 to 64 bit transition issue.
> 
> The problem seems to come when I attempt to access a function
> registered by the Matrix package.  During compilation (on 64 bit only)
> I get the ominous:
> 
> --
> slim_stolen_from_matrix.c: In function ‘R_as_cholmod_sparse’:
> slim_stolen_from_matrix.c:36: warning: implicit declaration of
> function ‘R_GetCCallable’
> slim_stolen_from_matrix.c:36: warning: cast to pointer from integer of
> different size


This is the key issue - you're missing the declaration of R_GetCCallable() as 
the compiler tells you, so the compiler assumes "int" as the return value. 
However, int is only 32-bit so it won't hold a 64-bit pointer and hence you're 
in trouble.

All you really need is

#include 

before you use R_GetCCallable and hopefully your issues should go away.

Note that your bug is there even in 32-bit -- you will see " implicit 
declaration of function" in any case -- it just is not fatal, incidentally. It 
is a good idea to listen to the compiler ... ;).

Cheers,
Simon


> --
> 
> The function in question is an identical copy of Matrix's
> M_as_cholmod_sparse, reproduced below
> 
> --
> CHM_SP
> R_as_cholmod_sparse(CHM_SP ans, SEXP x, Rboolean check_Udiag, Rboolean
> sort_in_place)
> {
>static CHM_SP(*fun)(CHM_SP,SEXP,Rboolean,Rboolean)= NULL;
>if(fun == NULL)
>   fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
>   R_GetCCallable("Matrix", "as_cholmod_sparse");
>return fun(ans, x, check_Udiag, sort_in_place);
> }
> --
> 
> I made this duplicate function since using Matrix's #include stubs
> conflicts with my copy of the CHOLMOD library (I need some functions
> Matrix doesn't make public).
> 
> When run, the code gives the following segfault when it reaches te
> first call to that function:
> 
> --
> Program received signal SIGSEGV, Segmentation fault.
> 0xf54314e2 in ?? ()
> *** caught segfault ***
> address 0xf54314e2, cause 'memory not mapped'
> --
> 
> As mentioned above, under valgrind the segault doesn't happen, but in
> GDB, the function pointer can be seen to have some problem.  In 64 bit
> --
> 35  fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
> (gdb) p fun
> $1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0
> (gdb) n
> 37  return fun(ans, x, check_Udiag, sort_in_place);
> (gdb) p fun
> $2 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xf54314e2
> --
> 
> vs 32bit
> --
> (gdb) p fun
> $1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xb72a3ec0
> 
> --
> 
> I've never done 64 bit development, so I don't know what I've probably
> done wrong.  I don't see an intermediate cast to an int to mess it up.
> Checking the pointer sizeof's seems like R_GetCCallable's return
> should be the same size as the function pointer.
> 
> --
> (gdb) p sizeof(void*)
> $5 = 8
> (gdb) p sizeof(CHM_SP*)
> $6 = 8
> (gdb) p sizeof(CHM_SP)
> $7 = 8
> (gdb) p sizeof(SEXP)
> $8 = 8
> (gdb) p sizeof(CHM_SP(*))
> $9 = 8
> (gdb) p sizeof(DL_FUNC)
> $10 = 8
> (gdb) p sizeof(DL_FUNC*)
> $11 = 8
> --
> 
> The function is invoked by
> --
> fitholder->Zt = R_as_cholmod_sparse
> ((CHM_SP)malloc(sizeof(cholmod_sparse)), Zt, TRUE, FALSE);
> ---
> 
> where Zt is a SEXP pointing to a Matrix-class sparse matrix passed by
> .Call from R.  CHM_SP is a typedef'd pointer to a cholmod_sparse
> 
> 
> 
>> sessionInfo()
> R version 2.12.1 (2010-12-16)
> Platform: x86_64-unknown-linux-gnu (64-bit)
> 
> locale:
> [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=C  LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> other attached packages:
> [1] emmpat_0.001   Matrix_0.999375-46 lattice_0.19-13
> 
> loaded via a namespace (and not attached):
> [1] grid_2.12.1
> 
> 
> Ryan King
> University of Chicago
> Dept. Health Studies
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

__
R-d

Re: [Rd] read.csv trap

[Ben Bolker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2011 03:37 PM, Laurent Gatto wrote:
> On 11 February 2011 19:39, Ben Bolker  wrote:
>>
> [snip]
>>
>> What is dangerous/confusing is that R silently **wraps** longer lines if
>> fill=TRUE (which is the default for read.csv).  I encountered this when
>> working with a colleague on a long, messy CSV file that had some phantom
>> extra fields in some rows, which then turned into empty lines in the
>> data frame.
>>
> 
> As a matter of fact, this is exactly what happened to a colleague of
> mine yesterday and caused her quite a bit of trouble. On the other
> hand, it could also be considered as a 'bug' in the csv file. Although
> no formal specification exist for the csv format, RFC 4180 [1]
> indicates that 'each line should contain the same number of fields
> throughout the file'.
> 
> [1] http://tools.ietf.org/html/rfc4180
> 
> Best wishes,
> 
> Laurent

  Asserting that the bug is in the CSV file is logically consistent, but
if this is true then the "fill=TRUE" argument (which is only needed when
the lines contain different numbers of fields) should not be allowed.

 I had never seen RFC4180 before -- interesting!  I note especially
points 5-7 which define the handling of double quotation marks (but says
nothing about single quotes or using backslashes as escape characters).

  Dealing with read.[table|csv] seems a bit of an Augean task
 (hmmm, maybe I should write a
parallel document to Burns's _Inferno_ ...)

  cheers
Ben

> 
>>  Here is an example and a workaround that runs count.fields on the
>> whole file to find the maximum column length and set col.names
>> accordingly.  (It assumes you don't already have a file named "test.csv"
>> in your working directory ...)
>>
>>  I haven't dug in to try to write a patch for this -- I wanted to test
>> the waters and see what people thought first, and I realize that
>> read.table() is a very complicated piece of code that embodies a lot of
>> tradeoffs, so there could be lots of different approaches to trying to
>> mitigate this problem. I appreciate very much how hard it is to write a
>> robust and general function to read data files, but I also think it's
>> really important to minimize the number of traps in read.table(), which
>> will often be the first part of R that new users encounter ...
>>
>>  A quick fix for this might be to allow the number of lines analyzed
>> for length to be settable by the user, or to allow a settable 'maxcols'
>> parameter, although those would only help in the case where the user
>> already knows there is a problem.
>>
>>  cheers
>>Ben Bolker
>>
>> ===
>> writeLines(c("A,B,C,D",
>> "1,a,b,c",
>> "2,f,g,c",
>> "3,a,i,j",
>> "4,a,b,c",
>> "5,d,e,f",
>> "6,g,h,i,j,k,l,m,n"),
>>   con=file("test.csv"))
>>
>>
>> read.csv("test.csv")
>> try(read.csv("test.csv",fill=FALSE))
>>
>> ## assumes header=TRUE, fill=TRUE; should be a little more careful
>> ##  with comment, quote arguments (possibly explicit)
>> ## ... contains information about quote, comment.char, sep
>> Read.csv <- function(fn,sep=",",...) {
>>  colnames <- scan(fn,nlines=1,what="character",sep=sep,...)
>>  ncolnames <- length(colnames)
>>  maxcols <- max(count.fields(fn,sep=sep,...))
>>  if (maxcols>ncolnames) {
>>colnames <- c(colnames,paste("V",(ncolnames+1):maxcols,sep=""))
>>  }
>>  ## assumes you don't have any other columns labeled "V[large number]"
>>  read.csv(fn,...,col.names=colnames)
>> }
>>
>> Read.csv("test.csv")
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1VsX4ACgkQc5UpGjwzenPwsgCfTtGo0kJSXhUTPcY+p7cgaiuq
zHAAnikRORUhqLP9O+6M5SwyZcFEW9uT
=Rb2R
-END PGP SIGNATURE-

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Writting my own package - 64 bit problem with R_GetCCallable

[Ryan King]

Ah thanks, that did fix it.

Ryan King

On Fri, Feb 11, 2011 at 3:53 PM, Simon Urbanek
 wrote:
> Ryan,
>
> On Feb 11, 2011, at 4:29 PM, Ryan King wrote:
>
>> Hello list,
>> I've been working on a package of my own.  It works fine on the 32bit
>> linux machines that I've tested it on.  Someone using 64bit ubuntu
>> wanted to try it, and surprising segfaults happened.  My test code
>> results in no segfault, errors, or leaks from my calls when run under
>> valgrind (I recompiled R with the level 2 valgrind instruments).  R
>> and packages are compiled from source, so this is hopefully not a
>> debian/ubuntu issue.  I'm totally stumped and hoping that this is a
>> silly / common 32 to 64 bit transition issue.
>>
>> The problem seems to come when I attempt to access a function
>> registered by the Matrix package.  During compilation (on 64 bit only)
>> I get the ominous:
>>
>> --
>> slim_stolen_from_matrix.c: In function ‘R_as_cholmod_sparse’:
>> slim_stolen_from_matrix.c:36: warning: implicit declaration of
>> function ‘R_GetCCallable’
>> slim_stolen_from_matrix.c:36: warning: cast to pointer from integer of
>> different size
>
>
> This is the key issue - you're missing the declaration of R_GetCCallable() as 
> the compiler tells you, so the compiler assumes "int" as the return value. 
> However, int is only 32-bit so it won't hold a 64-bit pointer and hence 
> you're in trouble.
>
> All you really need is
>
> #include 
>
> before you use R_GetCCallable and hopefully your issues should go away.
>
> Note that your bug is there even in 32-bit -- you will see " implicit 
> declaration of function" in any case -- it just is not fatal, incidentally. 
> It is a good idea to listen to the compiler ... ;).
>
> Cheers,
> Simon
>
>
>> --
>>
>> The function in question is an identical copy of Matrix's
>> M_as_cholmod_sparse, reproduced below
>>
>> --
>> CHM_SP
>> R_as_cholmod_sparse(CHM_SP ans, SEXP x, Rboolean check_Udiag, Rboolean
>> sort_in_place)
>> {
>>    static CHM_SP(*fun)(CHM_SP,SEXP,Rboolean,Rboolean)= NULL;
>>    if(fun == NULL)
>>       fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
>>           R_GetCCallable("Matrix", "as_cholmod_sparse");
>>    return fun(ans, x, check_Udiag, sort_in_place);
>> }
>> --
>>
>> I made this duplicate function since using Matrix's #include stubs
>> conflicts with my copy of the CHOLMOD library (I need some functions
>> Matrix doesn't make public).
>>
>> When run, the code gives the following segfault when it reaches te
>> first call to that function:
>>
>> --
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xf54314e2 in ?? ()
>> *** caught segfault ***
>> address 0xf54314e2, cause 'memory not mapped'
>> --
>>
>> As mentioned above, under valgrind the segault doesn't happen, but in
>> GDB, the function pointer can be seen to have some problem.  In 64 bit
>> --
>> 35              fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
>> (gdb) p fun
>> $1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0
>> (gdb) n
>> 37          return fun(ans, x, check_Udiag, sort_in_place);
>> (gdb) p fun
>> $2 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xf54314e2
>> --
>>
>> vs 32bit
>> --
>> (gdb) p fun
>> $1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xb72a3ec0
>> 
>> --
>>
>> I've never done 64 bit development, so I don't know what I've probably
>> done wrong.  I don't see an intermediate cast to an int to mess it up.
>> Checking the pointer sizeof's seems like R_GetCCallable's return
>> should be the same size as the function pointer.
>>
>> --
>> (gdb) p sizeof(void*)
>> $5 = 8
>> (gdb) p sizeof(CHM_SP*)
>> $6 = 8
>> (gdb) p sizeof(CHM_SP)
>> $7 = 8
>> (gdb) p sizeof(SEXP)
>> $8 = 8
>> (gdb) p sizeof(CHM_SP(*))
>> $9 = 8
>> (gdb) p sizeof(DL_FUNC)
>> $10 = 8
>> (gdb) p sizeof(DL_FUNC*)
>> $11 = 8
>> --
>>
>> The function is invoked by
>> --
>> fitholder->Zt = R_as_cholmod_sparse
>> ((CHM_SP)malloc(sizeof(cholmod_sparse)), Zt, TRUE, FALSE);
>> ---
>>
>> where Zt is a SEXP pointing to a Matrix-class sparse matrix passed by
>> .Call from R.  CHM_SP is a typedef'd pointer to a cholmod_sparse
>>
>>
>>
>>> sessionInfo()
>> R version 2.12.1 (2010-12-16)
>> Platform: x86_64-unknown-linux-gnu (64-bit)
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=C              LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>> [9] LC_ADDRESS=C               LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>> other attached packages:
>> [1] emmpat_0.001       Matrix_0.999375-46 lattice_0.19-13
>>
>> loaded via a namespace (and not attached):
>> [1] grid_2.12.1
>>
>>
>> Ryan King
>>

[Rd] R limits documented?

[Dominick Samperi]

Is there documentation on R limits?
That is, max matrix size, etc.?

Diagnostics when limits are exceeded are not always
meaningful. For example:
> x <- rep(0,5*5)
Error in rep(0, 5 * 5) : invalid 'times' argument
In addition: Warning message:
In as.vector(data) : NAs introduced by coercion

Here's another example:
> library(orthopolynom)
> hermite <- hermite.h.polynomials(1001)
> hermite[[1001]] # should display 1000-th degree polynomial
Error in if (signs[1] == "- ") "-" else "" :
  missing value where TRUE/FALSE needed

Thanks,
Dominick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R limits documented?

[David Winsemius]

On Feb 11, 2011, at 7:09 PM, Dominick Samperi wrote:


Is there documentation on R limits?
That is, max matrix size, etc.?

Diagnostics when limits are exceeded are not always
meaningful. For example:

x <- rep(0,5*5)

Error in rep(0, 5 * 5) : invalid 'times' argument
In addition: Warning message:
In as.vector(data) : NAs introduced by coercion


> x <- rep(0,4*5)
> gc()
 used(Mb) gc trigger(Mb)   max used(Mb)
Ncells4673306   249.66945861   371.05315868   283.9
Vcells 2165579376 16522.1 4374103452 33371.8 4165580443 31780.9
> object.size(x)
1600040 bytes

So that is about 2/3 of my installed memory. This seems to be a  
limitation due to the maximum positive integer being ~ 2*10^9

> 2*10^9 < 5*5
[1] TRUE
> 2*10^9 < 4*5
[1] FALSE



Here's another example:

library(orthopolynom)
hermite <- hermite.h.polynomials(1001)
hermite[[1001]] # should display 1000-th degree polynomial

Error in if (signs[1] == "- ") "-" else "" :
 missing value where TRUE/FALSE needed


Sounds as though the maximum length of an element of type character  
has been exceeded.


Thanks,
Dominick

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


David Winsemius, MD
West Hartford, CT

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R limits documented?

[Simon Urbanek]

On Feb 11, 2011, at 7:55 PM, David Winsemius wrote:

> 
> On Feb 11, 2011, at 7:09 PM, Dominick Samperi wrote:
> 
>> Is there documentation on R limits?
>> That is, max matrix size, etc.?
>> 
>> Diagnostics when limits are exceeded are not always
>> meaningful. For example:
>>> x <- rep(0,5*5)
>> Error in rep(0, 5 * 5) : invalid 'times' argument
>> In addition: Warning message:
>> In as.vector(data) : NAs introduced by coercion
> 
> > x <- rep(0,4*5)
> > gc()
> used(Mb) gc trigger(Mb)   max used(Mb)
> Ncells4673306   249.66945861   371.05315868   283.9
> Vcells 2165579376 16522.1 4374103452 33371.8 4165580443 31780.9
> > object.size(x)
> 1600040 bytes
> 
> So that is about 2/3 of my installed memory. This seems to be a limitation 
> due to the maximum positive integer being ~ 2*10^9
> > 2*10^9 < 5*5
> [1] TRUE
> > 2*10^9 < 4*5
> [1] FALSE
> 

The actual limit is for obvious reasons 2^31-1

> as.integer(2^31-1)
[1] 2147483647
> as.integer(2^31)
[1] NA
Warning message:
NAs introduced by coercion 

(ok, for those that this is not obvious: the integer type ("int" in C) is 
32-bit wide and it is a signed type so the range is -2^31-1 .. 2^31-1 -- the 
minus one on each side is the representation of NA and 0 respectively).

Cheers,
Simon


>> 
>> Here's another example:
>>> library(orthopolynom)
>>> hermite <- hermite.h.polynomials(1001)
>>> hermite[[1001]] # should display 1000-th degree polynomial
>> Error in if (signs[1] == "- ") "-" else "" :
>> missing value where TRUE/FALSE needed
> 
> Sounds as though the maximum length of an element of type character has been 
> exceeded.
>> 
>> Thanks,
>> Dominick
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> David Winsemius, MD
> West Hartford, CT
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R limits documented?

[Simon Urbanek]

On Feb 11, 2011, at 8:45 PM, Simon Urbanek wrote:

> 
> On Feb 11, 2011, at 7:55 PM, David Winsemius wrote:
> 
>> 
>> On Feb 11, 2011, at 7:09 PM, Dominick Samperi wrote:
>> 
>>> Is there documentation on R limits?
>>> That is, max matrix size, etc.?
>>> 
>>> Diagnostics when limits are exceeded are not always
>>> meaningful. For example:
 x <- rep(0,5*5)
>>> Error in rep(0, 5 * 5) : invalid 'times' argument
>>> In addition: Warning message:
>>> In as.vector(data) : NAs introduced by coercion
>> 
>>> x <- rep(0,4*5)
>>> gc()
>>used(Mb) gc trigger(Mb)   max used(Mb)
>> Ncells4673306   249.66945861   371.05315868   283.9
>> Vcells 2165579376 16522.1 4374103452 33371.8 4165580443 31780.9
>>> object.size(x)
>> 1600040 bytes
>> 
>> So that is about 2/3 of my installed memory. This seems to be a limitation 
>> due to the maximum positive integer being ~ 2*10^9
>>> 2*10^9 < 5*5
>> [1] TRUE
>>> 2*10^9 < 4*5
>> [1] FALSE
>> 
> 
> The actual limit is for obvious reasons 2^31-1
> 
>> as.integer(2^31-1)
> [1] 2147483647
>> as.integer(2^31)
> [1] NA
> Warning message:
> NAs introduced by coercion 
> 
> (ok, for those that this is not obvious: the integer type ("int" in C) is 
> 32-bit wide and it is a signed type so the range is -2^31-1 .. 2^31-1 -- the 
> minus one on each side is the representation of NA and 0 respectively).
> 

correction: the range should have read -(2^31-1) .. 2^31


> Cheers,
> Simon
> 
> 
>>> 
>>> Here's another example:
 library(orthopolynom)
 hermite <- hermite.h.polynomials(1001)
 hermite[[1001]] # should display 1000-th degree polynomial
>>> Error in if (signs[1] == "- ") "-" else "" :
>>> missing value where TRUE/FALSE needed
>> 
>> Sounds as though the maximum length of an element of type character has been 
>> exceeded.
>>> 
>>> Thanks,
>>> Dominick
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> David Winsemius, MD
>> West Hartford, CT
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 
> 

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R limits documented?

[David Winsemius]

On Feb 11, 2011, at 8:46 PM, Simon Urbanek wrote:



On Feb 11, 2011, at 8:45 PM, Simon Urbanek wrote:



On Feb 11, 2011, at 7:55 PM, David Winsemius wrote:



On Feb 11, 2011, at 7:09 PM, Dominick Samperi wrote:


Is there documentation on R limits?
That is, max matrix size, etc.?

Diagnostics when limits are exceeded are not always
meaningful. For example:

x <- rep(0,5*5)

Error in rep(0, 5 * 5) : invalid 'times' argument
In addition: Warning message:
In as.vector(data) : NAs introduced by coercion



x <- rep(0,4*5)
gc()

  used(Mb) gc trigger(Mb)   max used(Mb)
Ncells4673306   249.66945861   371.05315868   283.9
Vcells 2165579376 16522.1 4374103452 33371.8 4165580443 31780.9

object.size(x)

1600040 bytes

So that is about 2/3 of my installed memory. This seems to be a  
limitation due to the maximum positive integer being ~ 2*10^9

2*10^9 < 5*5

[1] TRUE

2*10^9 < 4*5

[1] FALSE



The actual limit is for obvious reasons 2^31-1


as.integer(2^31-1)

[1] 2147483647

as.integer(2^31)

[1] NA
Warning message:
NAs introduced by coercion

(ok, for those that this is not obvious: the integer type ("int" in  
C) is 32-bit wide and it is a signed type so the range is  
-2^31-1 .. 2^31-1 -- the minus one on each side is the  
representation of NA and 0 respectively).




correction: the range should have read -(2^31-1) .. 2^31


I was using the number given in the help page documentation for  
"integer". (Part of the question was whether it was "documented".) I  
did understand that it was d/t the 4 byte range.


Regarding the second part of the OP's question this is from the  
"character" help page:
"as.character truncates components of language objects to 500  
characters (was about 70 before 1.3.1)."


And there was a posting from Prof Ripley regarding some other  
limitations that had been recently modified:

https://stat.ethz.ch/pipermail/r-devel/2010-November/058989.html

--
David.




Cheers,
Simon



Here's another example:

library(orthopolynom)
hermite <- hermite.h.polynomials(1001)
hermite[[1001]] # should display 1000-th degree polynomial

Error in if (signs[1] == "- ") "-" else "" :
missing value where TRUE/FALSE needed


Sounds as though the maximum length of an element of type  
character has been exceeded.


Thanks,
Dominick




David Winsemius, MD
West Hartford, CT

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] using rasterImage within image

[Michael Sumner]

Hello, that appears to have fixed it. Thank you very much.

I can now repeat the reported workflow and the image appears on the
fifth (and subsequent) calls.

Cheers, Mike.

 sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-11 r54330)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

On Fri, Feb 11, 2011 at 12:41 PM, Paul Murrell  wrote:
> Hi
>
> Just committed another fix that solves this problem for me at least.  If you
> want to test for yourself, the magic revision number that you are looking
> for is r54330.
>
> Thanks again for your help.
>
> Paul
>
> On 10/02/2011 7:54 p.m., Michael Sumner wrote:
>>
>> Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
>> 2011-02-09 r54308.
>>
>> To reproduce, in a fresh R session (Windows in SDI mode):
>>
>> ## create a dummy dataset
>> m<- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)
>>
>> ## simple helper function to open the windows() device and plot the matrix
>> draw.f<- function(x) {
>>    plot(0, xlim = c(0, 1), ylim = c(0, 1))
>>    rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
>> }
>>
>> draw.f(m)
>>
>> ## repeat the following 2 lines five times:
>>
>> dev.off()
>> draw.f(m)
>>
>> On the fifth attempt, only the background plot appears - but the
>> raster is visible on resize of the windows() device.
>>
>> Cheers, Mike.
>>
>> sessionInfo()
>> R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
>> Platform: x86_64-pc-mingw32/x64 (64-bit)
>>
>> locale:
>> [1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
>> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
>> [5] LC_TIME=English_Australia.1252
>>
>> attached base packages:
>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>
>>
>>
>> On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
>>   wrote:
>>>
>>> Dear all,
>>>
>>> Back when grid.raster() was introduced, it was suggested that perhaps
>>> grid.rect() could use grid.raster() in case of even spacing. The
>>> response at the time was that it would be best to keep the two
>>> functions separate at a lower level, that is grid.rect() and
>>> grid.raster(), but perhaps a new function grid.image() could be
>>> proposed at a higher level with the two possible backends. If this is
>>> done in grid graphics, perhaps the same convention could be used for
>>> base graphics: image() would be high level with the backend option,
>>> and a new function ("tiles()", perhaps?) would implement the current
>>> behavior of image().
>>>
>>> In any case, it would be nice to have a unified scheme to switch
>>> between "tiles" and raster; currently lattice (panl.levelplot.raster)
>>> and a few other packages all do it separately.
>>>
>>> Best wishes,
>>>
>>> baptiste
>>>
>>>
>>>
>>> On 9 February 2011 23:29, Ben Bolker  wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>
> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>   wrote:
>>
>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>
>>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>>>   wrote:

 Ben,

 I have committed something analogous to R-devel (your rotation
 code was not unlike mine, I replicated the color handling from
 R internals to be consistent, I fixed the drawing limits and
 added a check for x/y conformance). Note that useRaster can
 only be used when x, y form a regular grid. Although I tried a
 lot of corner cases (requiring quite a few fixes), I'm sure I
 did not test all of them, so volunteers please give it a go and
 compare it with non-raster output.

 The only thing I'm not quite happy about is the argument name:
 useRaster. Personally, I hate camel case in R (it has crept in
 more recently making it horribly inconsistent) so please feel
 free to suggest a better name ;).
>>>
>>> It.is.spelled.camelCase.
>>>
>>
>> Fortunately not in English ;)
>>
>>
>>> What about style=c("image", "raster")?  This allows for future
>>> extensions too.
>>>
>>
>> Hmm.. it's not really a "style" - the output doesn't change
>> (ideally) - it's more of a back-end specification .. also we
>> already have oldstyle argument in image() adding to the confusion
>> ...
>
> flavor=c("image", "raster") renderer=c("image", "raster")
> backend=c("image", "raster") ...

  Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
 or do we need a warning/workaround there?)

  I like "backend", or possibly "method"

  One minor consideration: if "raster" eventu