[Rd] getGenerics returns names what are not generics
Hi there,
I encounter the following problem with getGenerics
when Rgraphviz is installed:
which(!sapply(getGenerics(), isGeneric))
#graph Rgraphviz graph Rgraphviz
# 105 106 107 108
so, getGenerics returns twice graph and Rgrapviz as being generics, when they
are not:
isGeneric("graph")
#FALSE
Best,
Vitalie.
R version 2.13.0 Under development (unstable) (2011-02-11 r54330)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] grid stats datasets grDevices utils graphics methods base
other attached packages:
[1] Rgraphviz_1.29.0 graph_1.28.0
loaded via a namespace (and not attached):
[1] tools_2.13.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] small suggestion---add sd to summary() for vectors, matrices, and data frames
Dear R developers---of course, I have my own function that does this, but I think this would be useful for others, too. summary() already returns the first moment, and I would hope most of us think of the standard deviation as a pretty common summary statistic. not to clutter this mailing list, but it would also be useful to have an optional parameter that creates a different type of output, stacking the univariate outputs, along the lines of for (i in 1:ncol(d)) cat(names(d)[i], summary(d[i]), "\n") of course, both of these suggestions may be useful but are not necessary. my biggest suggestion is still to issue an "ambiguity warning" when "<-[0-9]" is encountered, suggesting to users either to use '<-[ ][0-9]' or '<[ ]-[0-9]' spacing for disambiguation. this would help a lot of my students who are newcomers. regards, /iaw Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN package sizes
I think it would be even more useful if we could get Sweave to easily
produce PNG figures instead of just PDF/EPS. In the current state of
things, making PNG versions is more cumbersome than making PDF versions,
so I'm not surprised that most people don't go to that trouble most of
the time.
I also know (from searching the archives when I wanted to try this
myself) that a couple of people have, in the past, modified Sweave so it
can generate PNG automatically. However, the changes have never
migrated into the released version. Perhaps the space constraints at
CRAN can convince Freidrich Leisch that the change would be a good idea
Kevin
On 2/13/2011 3:02 PM, Yihui Xie wrote:
Regarding the reasons that make the doc directory large, I wonder if
we can make some changes in R:
1. Use a null graphics device as the default device rather than pdf()
when running Sweave -- this can avoid the useless Rplots.pdf:
options(device = function(...) {
.Call("R_GD_nullDevice", PACKAGE = "grDevices")
})
This can save some time in building the vignette(s) as well. (see
http://yihui.name/en/?p=673)
However, this undocumented null device may not work for certain
graphics. Here is an example that it fails for ggplot2:
http://stackoverflow.com/questions/4692974/ggplot2-code-that-works-interactively-rkward-crashes-under-lyx-pgfsweave-hint/4707745#4707745
Is it possible for someone to look into the null device (Dr Murrell?)
to make it stable enough?
2. Compress the PDF graphics and vignettes using third-party tools,
among which I recommend qpdf (it's free).
qpdf --stream-data=compress input.pdf output.pdf
This can reduce the size of PDF files a lot without quality loss. I'm
using this tool in the animation package to reduce the size of PDF
animations.
3. Sorry I bring up this issue again, but I don't understand why
Sweave could not implement the png() device along with pdf() and
postscript(). I'm willing to provide a patch if needed.
Thanks!
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Sun, Feb 13, 2011 at 6:30 AM, Prof Brian Ripley
wrote:
Robin Hankin's post reminded me to post about the following recent addition
to 'Writing R Extensions', in the section on 'Submitting a package to CRAN'
Ensure that the package sources are not unnecessarily large. ...
As a general rule, doc directories should not exceed 5Mb, and
where data directories need to be 10Mb or more, consideration should
be given to a separate package containing just the data. (Similarly
for external data directories, large jar files and other libraries
that need to be installed.)
With 2800 packages on CRAN, overall size is becoming a concern and currently
to install all of CRAN takes 4Gb. As the attached (I hope) graph shows, the
20 packages over 20Mb take a quarter, and those over 5Mb take half. (And
this is after we have removed 100Mb from the largest installed package by
re-compression, and archived the second largest, so Robin's package is
currently the largest.) Some of the largest packages are data/jar packages,
but there are 55 packages with 'doc' directories over 5Mb. To put that in
perspective, PDFs of whole books with lots of figures (MASS, Paul's R
Graphics) are well under 5Mb.
R CMD check in R-devel reports on large packages, and expect in future that
submitted package sizes will be questioned more often.
There are lots of different reasons why doc directories are large, but the
major ones are
- installing files that are unneeded, such as Rplots.pdf and .eps
figures.
- using PDF figures of images where PNG would be more appropriate.
- including less than relevant material (such as how to install R,
with screenshots!)
There are several ways to reduce the sizes of PDFs with no loss in quality,
e.g. Adobe Acrobat Standard/Pro.
--
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
__
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
[Rd] readPNG gives warnings and doesn't execute sample code from help files
Dear all, I noticed in the latest R version (R.2.12.1) that the readPNG gives following warning when running the example code in the help file (or when using any other png for that matter) : 50: In rasterImage(img, 1.2, 1.27, 1.8, 1.73) : Per-pixel alpha not supported on this device No picture is shown, and code I used to be able to run, doesn't run any more. > sessionInfo() R version 2.12.1 (2010-12-16) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C LC_TIME=English_United States.1252 attached base packages: [1] grDevices datasets splines graphics stats tcltk utils methods base other attached packages: [1] png_0.1-2 svSocket_0.9-51 TinnR_1.0.3 R2HTML_2.2 Hmisc_3.8-3 survival_2.36-2 loaded via a namespace (and not attached): [1] cluster_1.13.2 grid_2.12.1 lattice_0.19-13 svMisc_0.9-61 tools_2.12.1 -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readPNG gives warnings and doesn't execute sample code from help files
Joris, On Feb 14, 2011, at 10:05 AM, Joris Meys wrote: > Dear all, > > I noticed in the latest R version (R.2.12.1) that the readPNG gives > following warning when running the example code in the help file (or > when using any other png for that matter) : > > 50: In rasterImage(img, 1.2, 1.27, 1.8, 1.73) : > Per-pixel alpha not supported on this device > > No picture is shown, and code I used to be able to run, doesn't run any more. > You may want to use a device that supports alpha. The R logo in the example uses alpha so are probably the images you are using. If you don't want to (or can't) use a device that supports alpha, you'll have to flatten the alpha, - i.e. plot just img[,,1:3] However, most images don't have color where alpha is zero, so you'll have to replace it with the background color, e.g.: r = as.raster(img[,,1:3]) r[img[,,4] == 0] = "white" Cheers, Simon >> sessionInfo() > R version 2.12.1 (2010-12-16) > Platform: i386-pc-mingw32/i386 (32-bit) > > locale: > [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United > States.1252LC_MONETARY=English_United States.1252 > [4] LC_NUMERIC=C LC_TIME=English_United > States.1252 > > attached base packages: > [1] grDevices datasets splines graphics stats tcltk utils > methods base > > other attached packages: > [1] png_0.1-2 svSocket_0.9-51 TinnR_1.0.3 R2HTML_2.2 > Hmisc_3.8-3 survival_2.36-2 > > loaded via a namespace (and not attached): > [1] cluster_1.13.2 grid_2.12.1 lattice_0.19-13 svMisc_0.9-61 > tools_2.12.1 > > > -- > Joris Meys > Statistical consultant > > Ghent University > Faculty of Bioscience Engineering > Department of Applied mathematics, biometrics and process control > > tel : +32 9 264 59 87 > joris.m...@ugent.be > --- > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Paul Murrell auckland.ac.nz> writes:
>
> Hi
>
> On 12/02/2011 7:22 p.m., Michael Sumner wrote:
> > 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.
>
> Great. Thanks for checking.
>
> Paul
>
That's great.
Just a little bump: I would encourage Simon (in his copious spare
time), or other interested members of R-core, to decide on a good
name for the argument (as a reminder, I prefer 'method=c("raster","image")').
Furthermore, I would strongly encourage that "raster" be made the default
behavior for the development release of R ...
cheers
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R command line and pipe using in Linux?
Hi, I have a very large data file(GB) from which I only want to extract one column to draw histogram. This would be done several times, so I would like to ask if there is anyway to plot this using R from the linux command line, something look like this cut -f1 xxx.txt |RplotHist Thanks and hope to hear from you. Best regards, Hang [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
On 14 February 2011 18:26, Ben Bolker wrote:
> Paul Murrell auckland.ac.nz> writes:
>
>>
>> Hi
>>
>> On 12/02/2011 7:22 p.m., Michael Sumner wrote:
>> > 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.
>>
>> Great. Thanks for checking.
>>
>> Paul
>>
>
>
> That's great.
>
> Just a little bump: I would encourage Simon (in his copious spare
> time), or other interested members of R-core, to decide on a good
> name for the argument (as a reminder, I prefer 'method=c("raster","image")').
> Furthermore, I would strongly encourage that "raster" be made the default
> behavior for the development release of R ...
Seconded.
Also, I haven't had any comment on my suggestion, so I was wondering
if Grid graphics are meant to be left out of this question. Having
each package that uses Grid graphics implement its own version of
imageGrob() (e.g. lattice, ggplot2, RGraphics, gridExtra) with
optional use of raster format is probably not a very desirable
situation.
Best regards,
baptiste
>
> cheers
> Ben Bolker
>
> __
> 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 command line and pipe using in Linux?
Good afternoon Hang,
This is an example of what I've done with a csv file with a header
which is too big to read into memory.
# this is a file with about 50 columns and 28 million records
ap.fnam <- 'p2_all28m_records.csv'
# lets just explore the columns in Addresspoint...
# by reading in the header and the first row
p1 <- read.csv(ap.fnam, nrows=1)
# now which columns do we actually want?
# ok... in this case we only want the NCAT column...
cols.reqd <- grep('NCAT', names(p1))
# so we create a list containing this/these column(s) as a 'character'
# type and all other columns as 'NULL'...
col.classes <- ifelse(seq(ncol(p1)) %in% cols.reqd, 'character', 'NULL')
# this will likely take a little over a minute!
p9 <- read.csv(ap.fnam, colClasses=col.classes )
Hope this helps
Kind regards,
Sean
On 14 February 2011 17:40, Hang PHAN wrote:
> Hi,
> I have a very large data file(GB) from which I only want to extract one
> column to draw histogram. This would be done several times, so I would like
> to ask if there is anyway to plot this using R from the linux command line,
> something look like this
>
> cut -f1 xxx.txt |RplotHist
>
> Thanks and hope to hear from you.
> Best regards,
> Hang
>
> [[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 command line and pipe using in Linux?
On 14 February 2011 at 17:40, Hang PHAN wrote: | Hi, | I have a very large data file(GB) from which I only want to extract one | column to draw histogram. This would be done several times, so I would like | to ask if there is anyway to plot this using R from the linux command line, | something look like this | | cut -f1 xxx.txt |RplotHist Have a look at littler which was written with these uses in mind: http://dirk.eddelbuettel.com/code/littler.html It includes a few examples which should get you going. Also, in non-interactive mode, your plot device will have to a file. Hope this helps, Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R command line and pipe using in Linux?
On Mon, Feb 14, 2011 at 05:40:29PM +, Hang PHAN wrote:
> Hi,
> I have a very large data file(GB) from which I only want to extract one
> column to draw histogram. This would be done several times, so I would like
> to ask if there is anyway to plot this using R from the linux command line,
> something look like this
>
> cut -f1 xxx.txt |RplotHist
Hi Hang:
Can you use something like the following?
x <- as.numeric(system("cut -f1 xxx.txt", intern=TRUE))
According to ?system, long lines will be split, however, no limit
on the number of lines of the output is formulated there.
Petr Savicky.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
On Feb 14, 2011, at 12:26 PM, Ben Bolker wrote:
> Paul Murrell auckland.ac.nz> writes:
>
>>
>> Hi
>>
>> On 12/02/2011 7:22 p.m., Michael Sumner wrote:
>>> 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.
>>
>> Great. Thanks for checking.
>>
>> Paul
>>
>
>
> That's great.
>
> Just a little bump: I would encourage Simon (in his copious spare
> time), or other interested members of R-core, to decide on a good
> name for the argument (as a reminder, I prefer 'method=c("raster","image")').
> Furthermore, I would strongly encourage that "raster" be made the default
> behavior for the development release of R ...
>
Unfortunately I just encountered a speed bump today - I had no idea that the
Windows device doesn't even support transparent pixels. That needs to be fixed
before we can make it the default...
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using rasterImage within image
Hi
On 15/02/2011 8:11 a.m., Simon Urbanek wrote:
On Feb 14, 2011, at 12:26 PM, Ben Bolker wrote:
Paul Murrell auckland.ac.nz> writes:
Hi
On 12/02/2011 7:22 p.m., Michael Sumner wrote:
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.
Great. Thanks for checking.
Paul
That's great.
Just a little bump: I would encourage Simon (in his copious spare
time), or other interested members of R-core, to decide on a good
name for the argument (as a reminder, I prefer
'method=c("raster","image")'). Furthermore, I would strongly
encourage that "raster" be made the default behavior for the
development release of R ...
Unfortunately I just encountered a speed bump today - I had no idea
that the Windows device doesn't even support transparent pixels. That
needs to be fixed before we can make it the default...
See the table at the bottom of
http://developer.r-project.org/Raster/raster-RFC.html for the full list
of limitations.
Paul
Cheers, Simon
__ 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
On Feb 14, 2011, at 2:28 PM, Paul Murrell wrote:
> Hi
>
> On 15/02/2011 8:11 a.m., Simon Urbanek wrote:
>>
>> On Feb 14, 2011, at 12:26 PM, Ben Bolker wrote:
>>
>>> Paul Murrell auckland.ac.nz> writes:
>>>
Hi
On 12/02/2011 7:22 p.m., Michael Sumner wrote:
> 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.
Great. Thanks for checking.
Paul
>>>
>>>
>>> That's great.
>>>
>>> Just a little bump: I would encourage Simon (in his copious spare
>>> time), or other interested members of R-core, to decide on a good
>>> name for the argument (as a reminder, I prefer
>>> 'method=c("raster","image")'). Furthermore, I would strongly
>>> encourage that "raster" be made the default behavior for the
>>> development release of R ...
>>>
>>
>>
>> Unfortunately I just encountered a speed bump today - I had no idea
>> that the Windows device doesn't even support transparent pixels. That
>> needs to be fixed before we can make it the default...
>
> See the table at the bottom of
> http://developer.r-project.org/Raster/raster-RFC.html for the full list of
> limitations.
>
Mea culpa - I had forgotten that the default for interpolate=TRUE
(unfortunately) so all those dozens of warnings came from the fact that R was
trying to interpolate on a device that doesn't support it. I stand corrected,
transparent pixels are supported if interpolate=FALSE so image() should be safe.
Thanks,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R command line and pipe using in Linux?
Thanks for the prompt reply. I think I have an idea on how to do what I want now. Best regards, Hang On Mon, Feb 14, 2011 at 6:30 PM, Dirk Eddelbuettel wrote: > > On 14 February 2011 at 17:40, Hang PHAN wrote: > | Hi, > | I have a very large data file(GB) from which I only want to extract one > | column to draw histogram. This would be done several times, so I would > like > | to ask if there is anyway to plot this using R from the linux command > line, > | something look like this > | > | cut -f1 xxx.txt |RplotHist > > Have a look at littler which was written with these uses in mind: > > http://dirk.eddelbuettel.com/code/littler.html > > It includes a few examples which should get you going. Also, in > non-interactive mode, your plot device will have to a file. > > Hope this helps, Dirk > > -- > Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] drop argument for apply, rowSums, etc.
Dear list, dear Henrik,
I find myself often reconstructing matrices from the result of rowSum (matrix)
etc. I therefore propose a new argument, drop, for these functions:
drop = TRUE (default) is the current behaviour. With
drop = FALSE length (dim (x)) and dimnames are preserved and the affected
dimensions are set to 1 (or whatever teh result length of the applied function is)
I modified the base functions in colSums.R accordingly, and provide the
respective methods (I did not yet have the time to look into apply.R).
I'm wondering whether these changes are of sufficient interest to the R public
that these methods should have a more obvious "home" than a spectroscopy
package. As I learned this morning of package matrixStats: Henrik, would you
like to include these modified functions?
Anyways, the code is in the attached file, so if someone needs the funcionality,
he can find it here.
Claudia
--
Claudia Beleites
Dipartimento dei Materiali e delle Risorse Naturali
Università degli Studi di Trieste
Via Alfonso Valerio 6/a
I-34127 Trieste
phone: +39 0 40 5 58-37 68
email: cbelei...@units.it
# From base/R/colSums.R
.colSums <- function(x, na.rm = FALSE, dims = 1L, drop = TRUE)
{
if(is.data.frame(x)) x <- as.matrix(x)
if(!is.array(x) || length(dn <- dim(x)) < 2L)
stop("'x' must be an array of at least two dimensions")
if(dims < 1L || dims > length(dn) - 1L)
stop("invalid 'dims'")
n <- prod(dn[1L:dims])
dn [1L : dims] <- 1L
z <- if(is.complex(x))
.Internal(colSums(Re(x), n, prod(dn), na.rm)) +
1i * .Internal(colSums(Im(x), n, prod(dn), na.rm))
else .Internal(colSums(x, n, prod(dn), na.rm))
if (drop){
if(length(dn) > dims + 1L) {
dim(z) <- dn[-(1L:dims)]
dimnames(z) <- dimnames(x)[-(1L:dims)]
} else names(z) <- dimnames(x)[[dims+1]]
} else {
dim(z) <- dn
dimnames(z) <- dimnames(x)
}
z
}
.colMeans <- function(x, na.rm = FALSE, dims = 1L, drop = TRUE)
{
if(is.data.frame(x)) x <- as.matrix(x)
if(!is.array(x) || length(dn <- dim(x)) < 2L)
stop("'x' must be an array of at least two dimensions")
if(dims < 1L || dims > length(dn) - 1L)
stop("invalid 'dims'")
n <- prod(dn[1L:dims])
dn [1L : dims] <- 1L
z <- if(is.complex(x))
.Internal(colMeans(Re(x), n, prod(dn), na.rm)) +
1i * .Internal(colMeans(Im(x), n, prod(dn), na.rm))
else .Internal(colMeans(x, n, prod(dn), na.rm))
if (drop){
if(length(dn) > dims + 1L) {
dim(z) <- dn[-(1L:dims)]
dimnames(z) <- dimnames(x)[-(1L:dims)]
} else names(z) <- dimnames(x)[[dims+1]]
} else {
dim(z) <- dn
dimnames(z) <- dimnames(x)
}
z
}
.rowSums <- function(x, na.rm = FALSE, dims = 1L, drop = TRUE)
{
if(is.data.frame(x)) x <- as.matrix(x)
if(!is.array(x) || length(dn <- dim(x)) < 2L)
stop("'x' must be an array of at least two dimensions")
if(dims < 1L || dims > length(dn) - 1L)
stop("invalid 'dims'")
p <- prod(dn[-(1L:dims)])
dn [(dims + 1L) : length (dn)] <- 1L
z <- if(is.complex(x))
.Internal(rowSums(Re(x), prod(dn), p, na.rm)) +
1i * .Internal(rowSums(Im(x), prod(dn), p, na.rm))
else .Internal(rowSums(x, prod(dn), p, na.rm))
if (drop){
if(dims > 1L) {
dim(z) <- dn [1L:dims]
dimnames(z) <- dimnames(x)[1L:dims]
} else names(z) <- dimnames(x)[[1L]]
} else {
dim(z) <- dn
dimnames(z) <- dimnames(x)
}
z
}
.rowMeans <- function(x, na.rm = FALSE, dims = 1L, drop = TRUE)
{
if(is.data.frame(x)) x <- as.matrix(x)
if(!is.array(x) || length(dn <- dim(x)) < 2L)
stop("'x' must be an array of at least two dimensions")
if(dims < 1L || dims > length(dn) - 1L)
stop("invalid 'dims'")
p <- prod(dn[-(1L:dims)])
dn [(dims + 1L) : length (dn)] <- 1L
z <- if(is.complex(x))
.Internal(rowMeans(Re(x), prod(dn), p, na.rm)) +
1i * .Internal(rowMeans(Im(x), prod(dn), p, na.rm))
else .Internal(rowMeans(x, prod(dn), p, na.rm))
if (drop){
if(dims > 1L) {
dim(z) <- dn [1L:dims]
dimnames(z) <- dimnames(x)[1L:dims]
} else names(z) <- dimnames(x)[[1L]]
} else {
dim(z) <- dn
dimnames(z) <- dimnames(x)
}
z
}
test (.rowSums) <- function (){
a <- array (1:24, 4:2)
for (d in 1 : 2){
default <- base::rowSums (a, dims = d)
drop <- rowSums (a, dims = d, drop = TRUE)
nodrop <- rowSums (a, dims = d, drop = FALSE)
checkEquals (default, drop, sprintf ("base version ./. drop = TRUE, dim =
%i", d))
checkEquals (c (default), c (nodrop), sprintf ("drop = TRUE ./. FALSE, dim
= %i", d))
dd <- dim (default)
if (is.null (dd)) dd <- length (default)
checkEquals (dim (nodrop) [1 : d], dd, sprintf ("result dimensions, d =
%i", d))
}
}
test (.rowMeans) <- function (){
a <- array
Re: [Rd] using rasterImage within image
On 02/14/2011 02:59 PM, Simon Urbanek wrote:
>
> On Feb 14, 2011, at 2:28 PM, Paul Murrell wrote:
>
>> Hi
>>
>> On 15/02/2011 8:11 a.m., Simon Urbanek wrote:
>>>
>>> On Feb 14, 2011, at 12:26 PM, Ben Bolker wrote:
>>>
Paul Murrell auckland.ac.nz> writes:
>
> Hi
>
> On 12/02/2011 7:22 p.m., Michael Sumner wrote:
>> 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.
>
> Great. Thanks for checking.
>
> Paul
>
That's great.
Just a little bump: I would encourage Simon (in his copious
spare time), or other interested members of R-core, to decide
on a good name for the argument (as a reminder, I prefer
'method=c("raster","image")'). Furthermore, I would strongly
encourage that "raster" be made the default behavior for the
development release of R ...
>>>
>>>
>>> Unfortunately I just encountered a speed bump today - I had no
>>> idea that the Windows device doesn't even support transparent
>>> pixels. That needs to be fixed before we can make it the
>>> default...
>>
>> See the table at the bottom of
>> http://developer.r-project.org/Raster/raster-RFC.html for the full
>> list of limitations.
>>
>
> Mea culpa - I had forgotten that the default for interpolate=TRUE
> (unfortunately) so all those dozens of warnings came from the fact
> that R was trying to interpolate on a device that doesn't support it.
> I stand corrected, transparent pixels are supported if
> interpolate=FALSE so image() should be safe.
>
> Thanks, Simon
>
Yes, but: according to the table of limitations, this
image(matrix(1:9,3),
col=rgb(rep(1,9),rep(0,9),rep(0,9),alpha=seq(0,1,length=9)))
shouldn't work with raster under Windows.
"** The Windows device can do semitransparent raster images, but ONLY if
there is a constant alpha across the entire image, i.e., it CANNOT do
per-pixel alpha (the Windows API AlphaBlend can, but GraphApp's bitmap
structures do not support "shades of alpha" - it's either transparent or
opaque). The Windows device DOES support fully transparent pixels in an
image (possibly in addition to a single level of semitransparency). In
other words, the image can have up to three different levels of alpha,
as long as fully transparent and fully opaque are two of the three. "
I *think* the following function should provide a test of when we have
to fall back to method="image" if the current device is "windows" ...
diff_alpha <- function(cstr) {
alphastr <- substr(cstr[nchar(cstr)==9],8,9)
length(unique(alphastr[!alphastr %in% c("00","FF")]))>1
}
tst2 <- c(rgb(1,0,0,1),rgb(1,0,0),rgb(1,0,0,0.5),rgb(1,1,0,0.5),
rgb(1,0,0,0.7))
diff_alpha(tst2)
diff_alpha(tst2[1:4])
(I would argue that this situation is sufficiently rare that we should
still make "raster" the default, with a fallback to "image" if
diff_alpha() && windows is TRUE [perhaps a warning if missing(method)
and an error otherwise?])
Ben Bolker
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
