[Rd] 12-bit functionality in tiff package
Hi, We have recently been using the tiff package for reading tiff images into the Bioconductor Package EBImage. This has been extremely helpful in conjunction with other steps to eliminate dependencies on ImageMagick. However, it seems that 12-bit images are not supported. We were wondering if there are plans to extend the functionality of the readTIFF() function in the tiff package to accommodate 12-bit images? Best wishes, Joseph Barry (EMBL Heidelberg, Germany) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the current design of suppressWarnings() forces
me to ignore *any* warnings coming from the expression.
I started to write a new version that would check and, if supplied
with a regular expression, would only block matching warnings and
otherwise would produce the warnings as usual, but I don't quite know
enough about what I'm doing: see ??? in expression below.
Can anyone help, or suggest pointers to relevant
examples/documentation (I've looked at demo(error.catching), which isn't
helping me ... ?)
suppressWarnings2 <- function(expr,regex=NULL) {
opts <- options(warn = -1)
on.exit(options(opts))
I'm not really sure what the options(warn=-1) is doing there, maybe its for
efficiency to avoid generating a warning message (as distinct from signalling
The sources in srs/library/base/conditions.R have
suppressWarnings <- function(expr) {
ops <- options(warn = -1) ## FIXME: temporary hack until R_tryEval
on.exit(options(ops)) ## calls are removed from methods code
withCallingHandlers(expr,
warning=function(w)
invokeRestart("muffleWarning"))
}
I uspect we have still not entirely eliminated R_tryEval in this context
but I'm not sure. Will check when I get a chance.
a warning). I think you're after something like
suppressWarnings2 <-
function(expr, regex=character())
{
withCallingHandlers(expr, warning=function(w) {
if (length(regex) == 1 && length(grep(regex, conditionMessage(w {
invokeRestart("muffleWarning")
}
})
}
A problem with using expression matching is of course that this fails
with internationalized messages. Ideally warnings should be signaled as
warning conditions of a particular class, and that class can be used
to discriminate. Unfortunately very few warnings are designed this way.
Probably specific messages, rather than patterns, would be handled and then
suppressWarnings2 <- function(expr, messages = character())
{
opts <- options(warn = -1)
on.exit(options(ops))
withCallingHandlers(expr, warning=function(w) {
if (conditionMessage(w) %in% messages)
invokeRestart("muffleWarning")
})
}
gives one the illusion of speaking many languages
suppressWarnings2(log(-1), gettext("NaNs introduced", domain="R"))
Martin
Best,
luke
If the restart isn't invoked, then the next handler is called and the warning
is handled as normal. So with
f <- function() {
warning("oops")
2
}
there is
suppressWarnings2(f())
[1] 2
Warning message:
In f() : oops
suppressWarnings2(f(), "oops")
[1] 2
For your own code I think a better strategy is to create a sub-class of
warnings that can be handled differently
mywarn <-
function(..., call.=TRUE, immediate.=FALSE, domain=NULL)
{
msg <- .makeMessage(..., domain=domain, appendLF=FALSE)
call <- NULL
if (call.)
call <- sys.call(1L)
class <- c("silencable", "simpleWarning", "warning", "condition")
cond <- structure(list(message=msg, call=call), class=class)
warning(cond)
}
suppressWarnings3 <-
function(expr)
{
withCallingHandlers(expr, silencable=function(w) {
invokeRestart("muffleWarning")
})
}
then with
g <- function() {
mywarn("oops")
3
}
suppressWarnings3(f())
[1] 2
Warning message:
In f() : oops
g()
[1] 3
Warning message:
In g() : oops
suppressWarnings3(g())
[1] 3
withCallingHandlers(expr, warning = function(w) {
## browser()
if (is.null(regex) || grepl(w[["message"]],regex)) {
invokeRestart("muffleWarning")
} else {
## ? what do I here to get the warning issued?
## browser()
## computeRestarts() shows "browser",
##"muffleWarning", and "abort" ...
options(opts)
warning(w$message)
## how can I get back from here to the calling point
## *without* muffling warnings ... ?
}
})
}
suppressWarnings2(sqrt(-1))
suppressWarnings2(sqrt(-1),"abc")
It seems to me I'd like to have a restart option that just returns to
the point where the warning was caught, *without* muffling warnings ...
? But I don't quite understand how to set one up ...
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
Re: [Rd] R CMD SHLIB error bad value (core2) for -mtune= switch
Thank you so much Prof Ripley. You are right. So instead of using Windows R, I tried to compile binary R under Cygwin, but it errored out everytime at different places when I tried different options to configure. So I guess I need to seek other alternate ways. Is there any chance you think that I could find Windows C/C++ compilers (rather than Cygwin compilers) to compile the codes I mentioned that's written in conjuction with Linux R/C/C++, and then run the codes under Windows R? Or the only way out here is to spin up a linux machine to have R installed? Thanks, Yi -- View this message in context: http://r.789695.n4.nabble.com/R-CMD-SHLIB-error-bad-value-core2-for-mtune-switch-tp4645928p4647182.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
[Rd] Spurious warning when calling data() ?
Hi, When calling data, a warning seems to have been left behind data(package="stats", verbose=FALSE) Warning message: In data(package = "stats", verbose = FALSE) : datasets have been moved from package 'stats' to package 'datasets' (full version details further below). Best, Laurent sessionInfo() R version 2.15.1 Patched (2012-08-24 r60412) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_DK.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_DK.UTF-8LC_COLLATE=en_DK.UTF-8 [5] LC_MONETARY=en_DK.UTF-8LC_MESSAGES=en_DK.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_DK.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Spurious warning when calling data() ?
On 23/10/2012 3:20 PM, Laurent Gautier wrote: Hi, When calling data, a warning seems to have been left behind > data(package="stats", verbose=FALSE) Warning message: In data(package = "stats", verbose = FALSE) : datasets have been moved from package 'stats' to package 'datasets' What is spurious about that warning? It's still as true now as it was when the move happened several years ago. Duncan Murdoch (full version details further below). Best, Laurent > sessionInfo() R version 2.15.1 Patched (2012-08-24 r60412) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_DK.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_DK.UTF-8LC_COLLATE=en_DK.UTF-8 [5] LC_MONETARY=en_DK.UTF-8LC_MESSAGES=en_DK.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_DK.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 > __ 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] Spurious warning when calling data() ?
On 2012-10-23 21:43, Duncan Murdoch wrote: On 23/10/2012 3:20 PM, Laurent Gautier wrote: Hi, When calling data, a warning seems to have been left behind > data(package="stats", verbose=FALSE) Warning message: In data(package = "stats", verbose = FALSE) : datasets have been moved from package 'stats' to package 'datasets' What is spurious about that warning? It's still as true now as it was when the move happened several years ago. Beside the possible debate that a note about the moving might have more its place in release notes or documentation than in a warning message, shouldn't this disappear after one or may be two releases ? Duncan Murdoch (full version details further below). Best, Laurent > sessionInfo() R version 2.15.1 Patched (2012-08-24 r60412) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_DK.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_DK.UTF-8LC_COLLATE=en_DK.UTF-8 [5] LC_MONETARY=en_DK.UTF-8LC_MESSAGES=en_DK.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_DK.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 > __ 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] Spurious warning when calling data() ?
On 23/10/2012 20:20, Laurent Gautier wrote: Hi, When calling data, a warning seems to have been left behind data(package="stats", verbose=FALSE) Warning message: In data(package = "stats", verbose = FALSE) : datasets have been moved from package 'stats' to package 'datasets' Why do you think that is not an intentional warning for people who are using very old documentation? (full version details further below). Best, Laurent sessionInfo() R version 2.15.1 Patched (2012-08-24 r60412) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_DK.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_DK.UTF-8LC_COLLATE=en_DK.UTF-8 [5] LC_MONETARY=en_DK.UTF-8LC_MESSAGES=en_DK.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_DK.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.15.1 __ 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
Re: [Rd] 12-bit functionality in tiff package
Joseph Barry embl.de> writes: > We have recently been using the tiff package for reading tiff images > into the Bioconductor Package EBImage. This has been extremely > helpful in conjunction with other steps to eliminate dependencies on > ImageMagick. > However, it seems that 12-bit images are not supported. We were > wondering if there are plans to extend the functionality of the > readTIFF() function in the tiff package to accommodate 12-bit > images? It would probably be more efficient to query the package maintainer, which according to http://cran.r-project.org/web/packages/rtiff/ is Eric Kort __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 12-bit functionality in tiff package
Dear Ben, Many thanks for the reply. Actually, rtiff is a separate package to tiff. I have continued my correspondence with the latter's maintainer (Simon Urbanek) off-list. Perhaps I should have done this directly from the beginning, rather than going through list. Best wishes, Joseph Barry On Oct 23, 2012, at 11:10 PM, Ben Bolker wrote: > Joseph Barry embl.de> writes: > > >> We have recently been using the tiff package for reading tiff images >> into the Bioconductor Package EBImage. This has been extremely >> helpful in conjunction with other steps to eliminate dependencies on >> ImageMagick. > >> However, it seems that 12-bit images are not supported. We were >> wondering if there are plans to extend the functionality of the >> readTIFF() function in the tiff package to accommodate 12-bit >> images? > > It would probably be more efficient to query the package maintainer, > which according to > http://cran.r-project.org/web/packages/rtiff/ > > is > > Eric Kort > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typos/omissions/inconsistencies in man page for clusterApply
Hi,
Here are the issues I found:
Typos
-
(a) Found: It a parallel version of ‘evalq’,
"is" missing.
(b) Found: 'parLapplyLB', 'parSapplyLB' are load-balancing versions,
intended for use when applying ‘FUN’ to
'parLapplyLB' has no 'FUN' arg (more on this below).
(c) Found: 'clusterApply' calls 'fun' on the first node with arguments
'seq[[1]]' and
'clusterApply' has no 'seq' arg.
There are a few other occurences of mistake (c) in the \details
and \value section, for clusterApply() and clusterApplyLB().
Omissions
-
o X: A vector (atomic or list) for ‘parLapply’ and ‘parSapply’, an
array for ‘parApply’.
==> Nothing is said for the 'X' argument of parLapplyLB()
and parSapplyLB().
Inconsistencies
---
The only function in that man page with a 'seq' argument is
clusterSplit(), which is a questionable choice since split() (and
strsplit()) use 'x'. Choosing 'seq' is also inconsistent with all
the other cluster* and par* functions in that man page which use
either 'x' or 'X'. Unless this 'seq' argument is different in nature
but it doesn't seem so.
Also any reason why the argument receiving the function is sometimes
named 'fun' (parLapply), and sometimes 'FUN' (parSapply)? Especially
since the \note section says:
Two exceptions: ‘parLapply’ has argument ‘X’ not ‘x’ for
consistency with ‘lapply’, and ‘parSapply’ has been updated to
match ‘sapply’.
Well done for parSapply:
> args(parSapply)
function (cl = NULL, X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE)
NULL
> args(sapply)
function (X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE)
NULL
Not so well for parLapply (parLapply not consistent anymore with
snow:::parLapply but still not consistent with lapply):
> args(lapply)
function (X, FUN, ...)
NULL
> args(parLapply)
function (cl = NULL, X, fun, ...)
NULL
> args(snow::parLapply)
function (cl, x, fun, ...)
NULL
Same kind of problem with clusterMap (departing from snow::clusterMap
but not fully embracing naming convention used by mapply):
> args(mapply)
function (FUN, ..., MoreArgs = NULL, SIMPLIFY = TRUE, USE.NAMES = TRUE)
NULL
> args(clusterMap)
function (cl = NULL, fun, ..., MoreArgs = NULL, RECYCLE = TRUE,
SIMPLIFY = FALSE, USE.NAMES = TRUE, .scheduling = c("static",
"dynamic"))
NULL
> args(snow::clusterMap)
function (cl, fun, ..., MoreArgs = NULL, RECYCLE = TRUE)
NULL
Same problem with parRapply and parCapply and the naming of the x/X
argument:
> args(apply)
function (X, MARGIN, FUN, ...)
NULL
> args(parApply)
function (cl = NULL, X, MARGIN, FUN, ...)
NULL
> args(parRapply)
function (cl = NULL, x, FUN, ...)
NULL
> args(parCapply)
function (cl = NULL, x, FUN, ...)
NULL
Note that the naming of the arguments is not consistent with
snow::parRapply and snow::parCapply either:
> args(snow::parRapply)
function (cl, x, fun, ...)
NULL
> args(snow::parCapply)
function (cl, x, fun, ...)
NULL
and this exception (and maybe others) are not mentioned in the \note
section.
Overall it feels like the API for the 14 functions documented in this
man page could be a little bit cleaner.
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD SHLIB error bad value (core2) for -mtune= switch
On Oct 23, 2012, at 10:58 AM, smzyij wrote: > Thank you so much Prof Ripley. > > You are right. So instead of using Windows R, I tried to compile binary R > under Cygwin, but it errored out everytime at different places when I tried > different options to configure. So I guess I need to seek other alternate > ways. > > Is there any chance you think that I could find Windows C/C++ compilers > (rather than Cygwin compilers) to compile the codes I mentioned that's > written in conjuction with Linux R/C/C++, and then run the codes under > Windows R? Or the only way out here is to spin up a linux machine to have R > installed? > http://cran.r-project.org/bin/windows/base/rw-FAQ.html#Building-from-Source http://cran.r-project.org/doc/manuals/R-admin.html http://cran.r-project.org/doc/manuals/R-admin.html#Getting-the-tools http://cran.r-project.org/doc/manuals/R-admin.html#The-Windows-toolset > > -- > View this message in context: > http://r.789695.n4.nabble.com/R-CMD-SHLIB-error-bad-value-core2-for-mtune-switch-tp4645928p4647182.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 -- David Winsemius, MD Alameda, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
