date:20110210

Re: [Rd] Problem installing MCMCpack on SPARC Solaris 10

2011-02-10 Thread Prof Brian Ripley


On Thu, 10 Feb 2011, Prof Brian Ripley wrote:

There are lots of problems with MCMCpack's C++: the only way (short of a 
major rewrite) that you will get it to compile on Solaris is to use g++ (and 
even that needs corrections).


The maintainers seem deaf to reports of the issues.

And please note what the posting guide says about where to send questions 
about non-R programming issues.


Sorry, I omitted 'in contributed packages'.  And PLEASE don't post 
twice.


The patch I needed on x86 Solaris was

diff -ru tests32/MCMCpack/src/algorithm.h MCMCpack/src/algorithm.h
--- tests32/MCMCpack/src/algorithm.hMon Jan 31 17:28:11 2011
+++ MCMCpack/src/algorithm.hSun May 16 19:15:39 2010
@@ -45,6 +45,11 @@
 #include "scythestat/matrix_random_access_iterator.h"
 #endif

+#undef DO
+#undef DS
+#undef SO
+#undef SS
+




On Wed, 9 Feb 2011, Zhang,Jun wrote:


Hi list,
   I tried to install MCMCpack to R-2.12.0, got the following error,
R CMD INSTALL MCMCpack_1.0-9.tar.gz
..
CC -m64 -library=stlport4 -I/apps/sparcv9/R-2.12.0/lib/R/include 
-DSCYTHE_COMPILE_DIRECT -DSCYTHE_DEBUG=0 -DHAVE_TRUNC -DHAVE_IEEEFP_H 
-I/opt/csw/include-KPIC  -g -c MCMCSVDreg.cc -o 
MCMCSVDreg.o

"error.h", line 598: Error: The function "abort" must have a prototype.
"distributions.h", line 550: Error: The function "trunc" must have a 
prototype.

"distributions.h", line 550: Error: log1p is not a member of file level.
"distributions.h", line 566: Error: The function "trunc" must have a 
prototype.

"distributions.h", line 566: Error: log1p is not a member of file level.
"distributions.h", line 2177: Error: sqrt is not a member of file level.
6 Error(s) detected.
make: *** [MCMCSVDreg.o] Error 2
ERROR: compilation failed for package 'MCMCpack'
* removing '/apps/sparcv9/R-2.12.0/lib/R/library/MCMCpack'

root@dqssun4 local# which cc
/opt/solstudio12.2/bin/cc
root@dqssun4 local# which R
/apps/sparcv9/R-2.12.0/bin/R

The configure script for the successful R installation is the following,
CC="cc -xc99 -m64 -xarch=sparcvis2"
CPPFLAGS="-I/opt/csw/include"
CFLAGS="-xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2"
F77=f95
CXX="CC -m64 -library=stlport4"
FC=$F77
FFLAGS="-m64 -xarch=sparcvis2"
FCFLAGS=$FFLAGS
LDFLAGS="-L/opt/csw/lib/sparcv9 -L/opt/solstudio12.2/prod/lib/v9"
export CC CPPFLAGS CFLAGS F77 FFLAGS CXX CXXFLAGS FC FCFLAGS LDFLAGS
./configure --prefix=/apps/sparcv9/R-2.12.0 
--with-tcl-config=/opt/csw/lib/tclCo
nfig.sh --with-tk-config=/opt/csw/lib/tkConfig.sh 
--disable-nls


Jun Zhang

[[alternative HTML version deleted]]

__
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



--
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] BLAS optimization by CUBLAS

2011-02-10 Thread Юрий Посохов

Dear colleagues!

In early 2009 there was a discussion about fast BLAS library initiated by
Sachin. He reported a faster BLAS library made by Nvidia CUBLAS library. Uwe
Ligges showed an interest for placing the optimized rblas.dll into
windows/contrib section managed by him. Unfortunately there is no any CUBLAS
version of rblas.dll in this section at present. So, is anybody interested
in CUBLAS optimization of rblas now?

  In my opinion current directions (packages) of high-performance and
parallel computing with R suffer from grave shortcomings: all GPU
optimization is made by introducing more and more optimized functions
coexisting with original ones. This hard way has been chosen for Matlab too.
It complicates R as a language. So, the idea of optimizing BLAS (especially
by CUBLAS) seems to overcome the mentioned shortcomings. It might be
remarkable to make some efforts to this way of high-performance computing.

Yuri Possokhov

[[alternative HTML version deleted]]

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

[Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

2011-02-10 Thread Graham Williams

Should one expect minor numerical differences between 64bit and 32bit R on
Windows? Hunting around the lists I've not been able to find a definitive
answer yet. Seems plausible using different precision arithmetic, but waned
to confirm from those who might know for sure.

BACKGROUND

A colleague was trying to replicate some modelling results (from a soon to
be published book) using rpart, ada, and randomForest, for example. My 64bit
Linux and 64bit Windows 7 always agree (so far), but not their 32bit
Windows. I've distilled it to a few simple lines of code to replicate the
differences (but had to stay with the weather dataset from rattle since
could not replicate on standard datasets yet).

library(rpart)
library(rattle)
set.seed(41)
model <- rpart(RainTomorrow ~ ., data=weather[-c(1, 2,
23)], control=rpart.control(minbucket=0))
print(model$cptable)

Final row on 32bit: 9 0.0100 23 0.1515152 1.1060606 0.1158273
Final row on 64bit: 9 0.0100 23 0.1515152 1.0909091 0.1152273

Pretty minor, but different. I've not found any seed other than 41 (only
tried a few) that results in a difference.

library(ada) # using rpart underneath
set.seed(41)
model <- ada(RainTomorrow ~ ., data=weather[-c(1, 2, 23)])
print(model)

On 32bit: Train Error: 0.057
On 64bit: Train Error: 0.055

Changing the seed to 42, for example, brings them into sync.

library(randomForest)
set.seed(41)
model <- randomForest(RainTomorrow ~ ., data=weather[-c(1, 2, 23)],
  importance=TRUE, na.action=na.roughfix)
print(model)

On 32bit:  OOB estimate of  error rate: 12.84%
On 64bit:  OOB estimate of  error rate: 11.75%


> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: i386-pc-mingw32/i386 (32-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

other attached packages:
[1] randomForest_4.5-36 pmml_1.2.27 XML_3.2-0.2
[4] colorspace_1.0-1RGtk2_2.20.3ada_2.0-2
[7] rattle_2.6.2rpart_3.1-47

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

> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: x86_64-pc-mingw32/x64 (64-bit)
...


Thanks,
Graham

[[alternative HTML version deleted]]

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

Re: [Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

2011-02-10 Thread Duncan Murdoch


On 11-02-10 6:37 AM, Graham Williams wrote:

Should one expect minor numerical differences between 64bit and 32bit R on
Windows? Hunting around the lists I've not been able to find a definitive
answer yet. Seems plausible using different precision arithmetic, but waned
to confirm from those who might know for sure.


I think our goal is that those results should be as close as possible. 
R uses the same precision in both 32 bit and 64 bit; the differences are 
all in pointers, not floating point values.


However, the two versions use different run-time libraries, and it is 
possible that there are precision differences coming from there.  I 
think we'd be interested in knowing what they are even if they are 
beyond our control, so I would appreciate it if you could track down 
where the difference arises.


Duncan Murdoch



BACKGROUND

A colleague was trying to replicate some modelling results (from a soon to
be published book) using rpart, ada, and randomForest, for example. My 64bit
Linux and 64bit Windows 7 always agree (so far), but not their 32bit
Windows. I've distilled it to a few simple lines of code to replicate the
differences (but had to stay with the weather dataset from rattle since
could not replicate on standard datasets yet).

library(rpart)
library(rattle)
set.seed(41)
model<- rpart(RainTomorrow ~ ., data=weather[-c(1, 2,
23)], control=rpart.control(minbucket=0))
print(model$cptable)

Final row on 32bit: 9 0.0100 23 0.1515152 1.1060606 0.1158273
Final row on 64bit: 9 0.0100 23 0.1515152 1.0909091 0.1152273

Pretty minor, but different. I've not found any seed other than 41 (only
tried a few) that results in a difference.

library(ada) # using rpart underneath
set.seed(41)
model<- ada(RainTomorrow ~ ., data=weather[-c(1, 2, 23)])
print(model)

On 32bit: Train Error: 0.057
On 64bit: Train Error: 0.055

Changing the seed to 42, for example, brings them into sync.

library(randomForest)
set.seed(41)
model<- randomForest(RainTomorrow ~ ., data=weather[-c(1, 2, 23)],
   importance=TRUE, na.action=na.roughfix)
print(model)

On 32bit:  OOB estimate of  error rate: 12.84%
On 64bit:  OOB estimate of  error rate: 11.75%



sessionInfo()

R version 2.12.1 (2010-12-16)
Platform: i386-pc-mingw32/i386 (32-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

other attached packages:
[1] randomForest_4.5-36 pmml_1.2.27 XML_3.2-0.2
[4] colorspace_1.0-1RGtk2_2.20.3ada_2.0-2
[7] rattle_2.6.2rpart_3.1-47

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


sessionInfo()

R version 2.12.1 (2010-12-16)
Platform: x86_64-pc-mingw32/x64 (64-bit)
...


Thanks,
Graham

[[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] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

2011-02-10 Thread Petr Savicky

On Thu, Feb 10, 2011 at 10:37:09PM +1100, Graham Williams wrote:
> Should one expect minor numerical differences between 64bit and 32bit R on
> Windows? Hunting around the lists I've not been able to find a definitive
> answer yet. Seems plausible using different precision arithmetic, but waned
> to confirm from those who might know for sure.

One of the sources for the difference between platforms are different
settings of the compiler. On Intel processors, the options may influence,
whether the registers use 80 bit or 64 bit representation of floating
point numbers. In memory, it is always 64 bit. Testing, whether there is
a difference between registers and memory may be done for example using
the code

  #include 
  #define n 3
  int main(int agc, char *argv[])
  {
  double x[n];
  int i;
  for (i=0; ihttps://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] BLAS optimization by CUBLAS

2011-02-10 Thread Prof Brian Ripley


On Thu, 10 Feb 2011, Юрий Посохов wrote:


Dear colleagues!

In early 2009 there was a discussion about fast BLAS library initiated by
Sachin. He reported a faster BLAS library made by Nvidia CUBLAS library. Uwe
Ligges showed an interest for placing the optimized rblas.dll into
windows/contrib section managed by him. Unfortunately there is no any CUBLAS
version of rblas.dll in this section at present. So, is anybody interested
in CUBLAS optimization of rblas now?


We are, but we are primarily interested in maintainable Open Source 
solutions.  No one made available such a version of Rblas.dll (sic).



 In my opinion current directions (packages) of high-performance and
parallel computing with R suffer from grave shortcomings: all GPU
optimization is made by introducing more and more optimized functions
coexisting with original ones. This hard way has been chosen for Matlab too.
It complicates R as a language. So, the idea of optimizing BLAS (especially
by CUBLAS) seems to overcome the mentioned shortcomings. It might be
remarkable to make some efforts to this way of high-performance computing.

Yuri Possokhov

[[alternative HTML version deleted]]


Please do follow the posting guide and not send HTML.

--
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

Re: [Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

2011-02-10 Thread Prof Brian Ripley

A more important difference is the number of registers available on 
the CPU, which differs between i386 and x86_64.  Hence computations 
get done in different orders by optimizing compilers.


And yes, all x86_64 CPUs have SSE, so the optimizer uses them at the 
compiler settings we use.


As Duncan mentioned, the runtime (libc/m, on Windows mainly 
MSVCRT.dll) differs between OSes.


We know rather a lot about differences between platforms, as recent 
versions of R contain reference results for almost all the examples, 
and we from time to time compare output from CRAN check runs across 
platforms (this was part of the test suite run before releasing the 
64-bit Windows port).


Almost all the 64-bit platforms are very close (and agree exactly on 
the R examples), and 32-bit Solaris and Mac OS X are pretty close, 
32-bit Linux has quite a lot of differences, and 32-bit Windows 
somewhat more.


On Thu, 10 Feb 2011, Petr Savicky wrote:


On Thu, Feb 10, 2011 at 10:37:09PM +1100, Graham Williams wrote:

Should one expect minor numerical differences between 64bit and 32bit R on
Windows? Hunting around the lists I've not been able to find a definitive
answer yet. Seems plausible using different precision arithmetic, but waned
to confirm from those who might know for sure.


One of the sources for the difference between platforms are different
settings of the compiler. On Intel processors, the options may influence,
whether the registers use 80 bit or 64 bit representation of floating
point numbers. In memory, it is always 64 bit. Testing, whether there is
a difference between registers and memory may be done for example using
the code

 #include 
 #define n 3
 int main(int agc, char *argv[])
 {
 double x[n];
 int i;
 for (i=0; ihttps://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

Re: [Rd] embed Sweave driver in .Rnw file

2011-02-10 Thread Sharpie



Friedrich Leisch wrote:
> 
>> On Tue, 14 Dec 2010 12:40:04 +0100,
>> Romain Francois (RF) wrote:
> 
>   > Hello,
>   > Sweave lets you use alternative drivers through the driver argument,
> and 
>   > several packages take advantage of that and define custom Sweave
> driver 
>   > for various purposes. Most of them are listed on the Reproducible 
>   > Research CTV: 
>   > (http://cran.r-project.org/web/views/ReproducibleResearch.html)
> 
>   > The next natural step is for package developpers to take advantage of 
>   > this in their vignettes. In Rcpp we work around the way package
> building 
>   > works and we do:
>   > - let R build a dummy vignette
>   > - then use the inst/doc/Makefile to replace it with a vignette that is 
>   > processed by the driver from the highlight package (giving syntax 
>   > highlighting).
> 
>   > I played with Sweave so that it would be able to create the driver
> from 
>   > some text included in the text of the .Rnw file:
> 
>   > $ svn diff
>   > Index: src/library/utils/R/Sweave.R
>   > ===
>   > --- src/library/utils/R/Sweave.R  (revision 53846)
>   > +++ src/library/utils/R/Sweave.R  (working copy)
>   > @@ -20,6 +20,16 @@
>   >   # We don't need srclines for code, but we do need it for text, and 
>   > it's easiest
>   >   # to just keep it for everything.
> 
>   > +SweaveGetDriver <- function(file){
>   > +txt <- readLines(file)
>   > +line <- grep( "\\SweaveDriver", txt, value = TRUE )
>   > +if( length(line) ){
>   > +txt <- sub( "^.*\\SweaveDriver[{](.*)[}]", "\\1", line[1L] )
>   > +driver <- try( eval( parse( text = txt ) ), silent = TRUE )
>   > +if( !inherits( driver, "try-error") ) driver
>   > +}
>   > +}
>   > +
>   >   Sweave <- function(file, driver=RweaveLatex(),
>   >  syntax=getOption("SweaveSyntax"), ...)
>   >   {
>   > @@ -28,7 +38,9 @@
>   >   else if(is.function(driver))
>   >   driver <- driver()
> 
>   > -
>   > +drv <- SweaveGetDriver(file)
>   > +if( !is.null(drv) ) driver <- drv
>   > +
>   >   if(is.null(syntax))
>   >   syntax <- SweaveGetSyntax(file)
>   >   if(is.character(syntax))
> 
> 
> 
>   > This allows one to write something like this in their file:
> 
>   > %\SweaveDriver{ { require(highlight); HighlightWeaveLatex() } }
> 
>   > So that when calling :
> 
>   >> Sweave( "somefile.Rnw" )
> 
>   > the highlight driver is used instead of the default driver.
> 
>   > Could something like that be added to Sweave ?
> 
> Yes, sure!
> 
> Will have a look at the patch later this week and apply it if it
> passes the tests. The patch is against a current r-devel?
> 
> Best,
> Fritz
> 


Is there an update on the status of this patch?  I use a particularly ugly
hack to splice a custom driver into one of my package Vignettes and it would
be great to retire it in favor of an officially supported method.

-Charlie  

-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
-- 
View this message in context: 
http://r.789695.n4.nabble.com/embed-Sweave-driver-in-Rnw-file-tp3086897p3300339.html
Sent from the R devel mailing list archive at Nabble.com.

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

Re: [Rd] using rasterImage within image

2011-02-10 Thread Paul Murrell


Hi

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.


Bother.  Thanks very much for testing.  I'll keep looking.

Paul


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" eventually becomes the default
(as I hope it will), there would need to be some internal logic that
drops back to "image" if the user specifies uneven spacing and doesn't
explicitly specify the 'backend/method' parameter ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
=/da6
-END PGP SIGNATURE-

__
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







--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

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

Re: [Rd] using rasterImage within image

2011-02-10 Thread Paul Murrell


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" eventually becomes the default
(as I hope it will), there would need to be some internal logic that
drops back to "image" if the user specifies uneven spacing and doesn't
explicitly specify the 'backend/method' parameter ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
=/da6
-END PGP SIGNATURE-

__
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







--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

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

[Rd] R project testers - how to help out

2011-02-10 Thread James Goss



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

Re: [Rd] Problem installing MCMCpack on SPARC Solaris 10

[Rd] BLAS optimization by CUBLAS

[Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

Re: [Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

Re: [Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

Re: [Rd] BLAS optimization by CUBLAS

Re: [Rd] R 2.12.1 Windows 32bit and 64bit - are numerical differences expected?

Re: [Rd] embed Sweave driver in .Rnw file

Re: [Rd] using rasterImage within image

Re: [Rd] using rasterImage within image

[Rd] R project testers - how to help out

11 matches

Site Navigation

Mail list logo

Footer information