[Rd] ifelse behaviour
Hi! I'm puzzled by the return value of ifelse consider x<-integer(0) ifelse(is(x, "character"), paste(x), x) [1] NA whereas if (is(x, "character")) return(paste(x)) else x [1] integer(0) or x<-integer(1) ifelse(is(x, "character"), paste(x), x) [1] 0 work as I had anticipated. Is this correct behaviour? Regards, Matthias >sessionInfo() R version 2.5.0 (2007-04-23) i686-pc-linux-gnu locale: C attached base packages: [1] "stats" "graphics" "grDevices" "datasets" "utils" "methods" [7] "base" other attached packages: rcompletionrcompgen "0.1-2""0.1-10" -- Matthias Burger Project Manager/ Biostatistician Epigenomics AGKleine Praesidentenstr. 110178 Berlin, Germany phone:+49-30-24345-371 fax:+49-30-24345-555 http://www.epigenomics.com [EMAIL PROTECTED] -- Epigenomics AG Berlin Amtsgericht Charlottenburg HRB 75861 Vorstand: Geert Nygaard (CEO/Vorsitzender), Dr. Kurt Berlin (CSO) Oliver Schacht PhD (CFO), Christian Piepenbrock (COO) Aufsichtsrat: Prof. Dr. Dr. hc. Rolf Krebs (Chairman/Vorsitzender) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ifelse behaviour
On 4/26/2007 9:53 AM, [EMAIL PROTECTED] wrote: > Hi! > > I'm puzzled by the return value of ifelse > > consider > > x<-integer(0) > ifelse(is(x, "character"), paste(x), x) > [1] NA The test evaluates to a length 1 logical vector containing FALSE. So ifelse() tries to return the first entry of x. But x[1] doesn't exist, so it evaluates to NA, and that's what ifelse() returns. > > whereas > if (is(x, "character")) return(paste(x)) else x > [1] integer(0) This is quite different. It says to return the expression in the else clause, which is x. > > or > x<-integer(1) > ifelse(is(x, "character"), paste(x), x) > [1] 0 > > work as I had anticipated. Is this correct behaviour? Yes, this is correct. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ifelse behaviour
A simpler version of your "puzzling call to ifelse" is ifelse(FALSE, character(0), integer(0)) The most obvious way to satisfy the requirements stated in the documentation is to extend integer(0) to length 1 by creating an NA value, and that's what you get as a return value (here the 'test' argument has length 1, and the 'no' argument has length 0). -- Tony Plate [EMAIL PROTECTED] wrote: > Hi! > > I'm puzzled by the return value of ifelse > > consider > > x<-integer(0) > ifelse(is(x, "character"), paste(x), x) > [1] NA > > whereas > if (is(x, "character")) return(paste(x)) else x > [1] integer(0) > > or > x<-integer(1) > ifelse(is(x, "character"), paste(x), x) > [1] 0 > > work as I had anticipated. Is this correct behaviour? > > Regards, > >Matthias > > > >sessionInfo() > R version 2.5.0 (2007-04-23) > i686-pc-linux-gnu > > locale: > C > > attached base packages: > [1] "stats" "graphics" "grDevices" "datasets" "utils" "methods" > [7] "base" > > other attached packages: > rcompletionrcompgen > "0.1-2""0.1-10" > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ifelse behaviour
Duncan Murdoch wrote: > On 4/26/2007 9:53 AM, [EMAIL PROTECTED] wrote: >> Hi! >> >> I'm puzzled by the return value of ifelse >> >> consider >> >> x<-integer(0) >> ifelse(is(x, "character"), paste(x), x) >> [1] NA > > The test evaluates to a length 1 logical vector containing FALSE. So > ifelse() tries to return the first entry of x. But x[1] doesn't exist, > so it evaluates to NA, and that's what ifelse() returns. Thank you for the explanation! Regards, Matthias >> >> whereas >> if (is(x, "character")) return(paste(x)) else x >> [1] integer(0) > > This is quite different. It says to return the expression in the else > clause, which is x. >> >> or >> x<-integer(1) >> ifelse(is(x, "character"), paste(x), x) >> [1] 0 >> >> work as I had anticipated. Is this correct behaviour? > > Yes, this is correct. > > Duncan Murdoch > -- Matthias Burger Project Manager/ Biostatistician Epigenomics AGKleine Praesidentenstr. 110178 Berlin, Germany phone:+49-30-24345-371 fax:+49-30-24345-555 http://www.epigenomics.com [EMAIL PROTECTED] -- Epigenomics AG Berlin Amtsgericht Charlottenburg HRB 75861 Vorstand: Geert Nygaard (CEO/Vorsitzender), Dr. Kurt Berlin (CSO) Oliver Schacht PhD (CFO), Christian Piepenbrock (COO) Aufsichtsrat: Prof. Dr. Dr. hc. Rolf Krebs (Chairman/Vorsitzender) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] path autocompletion in 2.5.0
Hi,
R 2.5.0 isn't auto-completing paths properly as it used to. E.g.
suppose I have:
> dir("CEL/choe")
[1] "chipC-rep1.CEL" "chipC-rep2.CEL" "chipC-rep3.CEL" "chipS-rep1.CEL"
[5] "chipS-rep2.CEL" "chipS-rep3.CEL"
Now if I do:
ReadAffy("CEL/choe/ch # => ReadAffy("CEL/choe/chip
ReadAffy("CEL/choe/chipC # => ReadAffy("CEL/choe/chipC-rep
ReadAffy("CEL/choe/chipC-rep1 # Nothing happens.
in 2.4.1 that final line auto-completes properly to:
ReadAffy("CEL/choe/chipC-rep1.CEL"
Cheers,
Ernest
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] path autocompletion in 2.5.0
Did you actually look at the NEWS file?
o The Unix-alike readline terminal interface now does
command-completion for R objects, incorporating the
functionality formerly in package 'rcompletion' by Deepayan
Sarkar. This can be disabled by setting the environment
variable R_COMPLETION=FALSE when starting R (e.g. in
~/.Renviron). (Note that when this is enabled, filename
completion no longer works for file paths containing R
operators such as '+' and '-'.)
What 'properly' means is of course a matter of taste, but I am very
surprised that you posted such a comment about something highlighted under
USER-VISIBLE CHANGES as a configurable option.
R-devel has an option to fine-tune this behaviour.
On Thu, 26 Apr 2007, Ernest Turro wrote:
> Hi,
>
> R 2.5.0 isn't auto-completing paths properly as it used to. E.g.
> suppose I have:
>
> > dir("CEL/choe")
> [1] "chipC-rep1.CEL" "chipC-rep2.CEL" "chipC-rep3.CEL" "chipS-rep1.CEL"
> [5] "chipS-rep2.CEL" "chipS-rep3.CEL"
>
> Now if I do:
>
> ReadAffy("CEL/choe/ch # => ReadAffy("CEL/choe/chip
> ReadAffy("CEL/choe/chipC # => ReadAffy("CEL/choe/chipC-rep
> ReadAffy("CEL/choe/chipC-rep1 # Nothing happens.
>
> in 2.4.1 that final line auto-completes properly to:
>
> ReadAffy("CEL/choe/chipC-rep1.CEL"
>
> Cheers,
>
> Ernest
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] path autocompletion in 2.5.0
Read release note of 2.5.0. It is mentioned there.
Ernest Turro wrote:
> Hi,
>
> R 2.5.0 isn't auto-completing paths properly as it used to. E.g.
> suppose I have:
>
> > dir("CEL/choe")
> [1] "chipC-rep1.CEL" "chipC-rep2.CEL" "chipC-rep3.CEL" "chipS-rep1.CEL"
> [5] "chipS-rep2.CEL" "chipS-rep3.CEL"
>
> Now if I do:
>
> ReadAffy("CEL/choe/ch # => ReadAffy("CEL/choe/chip
> ReadAffy("CEL/choe/chipC # => ReadAffy("CEL/choe/chipC-rep
> ReadAffy("CEL/choe/chipC-rep1 # Nothing happens.
>
> in 2.4.1 that final line auto-completes properly to:
>
> ReadAffy("CEL/choe/chipC-rep1.CEL"
>
> Cheers,
>
> Ernest
>
> __
> 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] path autocompletion in 2.5.0
Apologies for missing that in NEWS.
Apart for auto-completion breaking for paths with '-', this sounds
very convenient.
E
On 26 Apr 2007, at 17:30, Prof Brian Ripley wrote:
> Did you actually look at the NEWS file?
>
> o The Unix-alike readline terminal interface now does
> command-completion for R objects, incorporating the
> functionality formerly in package 'rcompletion' by Deepayan
> Sarkar. This can be disabled by setting the environment
> variable R_COMPLETION=FALSE when starting R (e.g. in
> ~/.Renviron). (Note that when this is enabled, filename
> completion no longer works for file paths containing R
> operators such as '+' and '-'.)
>
> What 'properly' means is of course a matter of taste, but I am very
> surprised that you posted such a comment about something
> highlighted under USER-VISIBLE CHANGES as a configurable option.
>
> R-devel has an option to fine-tune this behaviour.
>
>
> On Thu, 26 Apr 2007, Ernest Turro wrote:
>
>> Hi,
>>
>> R 2.5.0 isn't auto-completing paths properly as it used to. E.g.
>> suppose I have:
>>
>> > dir("CEL/choe")
>> [1] "chipC-rep1.CEL" "chipC-rep2.CEL" "chipC-rep3.CEL" "chipS-
>> rep1.CEL"
>> [5] "chipS-rep2.CEL" "chipS-rep3.CEL"
>>
>> Now if I do:
>>
>> ReadAffy("CEL/choe/ch # => ReadAffy("CEL/choe/chip
>> ReadAffy("CEL/choe/chipC # => ReadAffy("CEL/choe/chipC-rep
>> ReadAffy("CEL/choe/chipC-rep1 # Nothing happens.
>>
>> in 2.4.1 that final line auto-completes properly to:
>>
>> ReadAffy("CEL/choe/chipC-rep1.CEL"
>>
>> Cheers,
>>
>> Ernest
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem with R-2.5.0 patched and Matrix package
Hi, Using latest R 2.5.0 Patched, I'm unable to install the Matrix package from cran.fhcrc.org. I get: Creating a new generic function for "isSymmetric" in "Matrix" Creating a new generic function for "unname" in "Matrix" Error in conformMethod(signature, mnames, fnames, f) : In method for function "!": formal arguments omitted in the method definition cannot be in the signature (x = "Matrix") Error: unable to load R code in package 'Matrix' Execution halted ERROR: lazy loading failed for package 'Matrix' ** Removing '/home/sfalcon/RLIBS/2.5/Matrix' ** Restoring previous '/home/sfalcon/RLIBS/2.5/Matrix' The downloaded packages are in /tmp/RtmpcEQJjw/downloaded_packages Warning message: installation of package 'Matrix' had non-zero exit status in: install.packages(pkgs = pkgs, repos = repos, dependencies = dependencies, I don't have this problem when using a recent R-devel. And I'm guessing that Matrix works with the release, but haven't had time to check this. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Signature of '!' (was Problem with R-2.5.0 patched and Matrix package)
Yes, it works in the release.
The essence of the problem is that Matrix defines an S4 method for '!'
with dispatch on 'e1', but the documentation for '!' (and many S3 methods)
says the argument is 'x'. As '!' is a primitive the argument matching of
the base function might be expected to be positional only, but that is not
what happens with methods.
This needs some juggling, and clearly two patches in R-patched have
conflicted. I've reverted one of them and this seems to work again (but
something else no longer works: see below).
Longer term, I don't know what the right way forward is. Consider
> setClass("foo", "logical")
[1] "foo"
> setMethod("!", "foo", function(e1) NA)
[1] "!"
> x <- new("foo", TRUE)
> !x
[1] NA
> `!`(x)
[1] NA
> `!`(x=x)
Error in !x : unused argument(s) (x = TRUE)
> `!`(e1=x)
[1] NA
which is not what the reader of the help for '!' might expect. But it
gets worse:
> x2 <- structure(TRUE, class="bar")
> `!.bar` <- function(x) NA
(and there are several S3 methods like that in CRAN packages)
> !x2
[1] NA
> `!`(x2)
[1] NA
> `!`(x=x2)
Error in !x2 : unused argument(s) (x = TRUE)
> `!`(e1=x2)
Error in `!.bar`(e1 = x2) : unused argument(s) (e1 = TRUE)
whereas `!`(x=x2) does work if you do not set an S4 method on '!'.
This may seem artificial, but this sort of thing can happen if you use
operators as functions in lapply().
Since there are in packages S3 methods on 'x' and S4 methods on 'e1', we
have a conflict.
My gut feeling is that the inconsistency is the S4 signature, and
certainly that seems the easier one to change. I knew about this because
the behind-the-scenes S4 generics in R-devel are auto-generated from the
descriptions of the primitives. Now in 2.5.0 you will see
> `!`
function (x) .Primitive("!")
and hence there needed to be an exclusion list (which now includes '!' and
'c') to have Matrix work in R-devel. An alternative is to make the
internal method dispatch on operators ignore the argument names.
(I can guess where this comes from. '!' is a member of the S3 Ops group,
and as part of a group method you define Ops(e1, e2) and ignore e2. But
'!' is not part of the S4 group generic Logic in R.)
Thanks for the report.
On Thu, 26 Apr 2007, Seth Falcon wrote:
> Hi,
>
> Using latest R 2.5.0 Patched, I'm unable to install the Matrix package
> from cran.fhcrc.org.
>
> I get:
>
> Creating a new generic function for "isSymmetric" in "Matrix"
> Creating a new generic function for "unname" in "Matrix"
> Error in conformMethod(signature, mnames, fnames, f) :
>In method for function "!": formal arguments omitted in the method
> definition cannot be in the signature (x = "Matrix")
> Error: unable to load R code in package 'Matrix'
> Execution halted
> ERROR: lazy loading failed for package 'Matrix'
> ** Removing '/home/sfalcon/RLIBS/2.5/Matrix'
> ** Restoring previous '/home/sfalcon/RLIBS/2.5/Matrix'
>
> The downloaded packages are in
>/tmp/RtmpcEQJjw/downloaded_packages
> Warning message:
> installation of package 'Matrix' had non-zero exit status in:
> install.packages(pkgs = pkgs, repos = repos, dependencies = dependencies,
>
> I don't have this problem when using a recent R-devel. And I'm
> guessing that Matrix works with the release, but haven't had time to
> check this.
>
> + seth
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] evaluation in unattached namespace
Hi,
I recently discovered this buglet in lattice: If lattice is _not_
attached, I get
> lattice::dotplot(~1:10)
Error in eval(expr, envir, enclos) : could not find function "bwplot"
This happens because of this:
> lattice:::dotplot.formula
function (x, data = NULL, panel = "panel.dotplot", ...)
{
ocall <- ccall <- match.call()
ccall$data <- data
ccall$panel <- panel
ccall[[1]] <- as.name("bwplot")
ans <- eval.parent(ccall)
ans$call <- ocall
ans
}
That is, ccall is eval()-ed in the global environment where bwplot is
not visible. While this example is somewhat silly, similar things
happen when I try to import lattice from another package.
Are there any simple alternatives? I tried
ccall[[1]] <- as.name("lattice::bwplot")
but that didn't work either.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] evaluation in unattached namespace
On 4/26/2007 7:39 PM, Deepayan Sarkar wrote:
> Hi,
>
> I recently discovered this buglet in lattice: If lattice is _not_
> attached, I get
>
>> lattice::dotplot(~1:10)
> Error in eval(expr, envir, enclos) : could not find function "bwplot"
>
> This happens because of this:
>
>> lattice:::dotplot.formula
> function (x, data = NULL, panel = "panel.dotplot", ...)
> {
> ocall <- ccall <- match.call()
> ccall$data <- data
> ccall$panel <- panel
> ccall[[1]] <- as.name("bwplot")
> ans <- eval.parent(ccall)
> ans$call <- ocall
> ans
> }
>
>
> That is, ccall is eval()-ed in the global environment where bwplot is
> not visible. While this example is somewhat silly, similar things
> happen when I try to import lattice from another package.
>
> Are there any simple alternatives? I tried
>
> ccall[[1]] <- as.name("lattice::bwplot")
>
> but that didn't work either.
One way would be to create a new environment with the caller's
environment as the parent, and put a copy of bwplot in it, i.e.
something like the following untested code:
function (x, data = NULL, panel = "panel.dotplot", ...)
{
ocall <- ccall <- match.call()
ccall$data <- data
ccall$panel <- panel
ccall[[1]] <- as.name("bwplot")
evalenv <- new.env(parent = parent.frame())
assign("bwplot", bwplot, envir=evalenv)
ans <- eval(ccall, envir=evalenv)
ans$call <- ocall
ans
}
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] evaluation in unattached namespace
On 4/26/07, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 4/26/2007 7:39 PM, Deepayan Sarkar wrote:
> > Hi,
> >
> > I recently discovered this buglet in lattice: If lattice is _not_
> > attached, I get
> >
> >> lattice::dotplot(~1:10)
> > Error in eval(expr, envir, enclos) : could not find function "bwplot"
> >
> > This happens because of this:
> >
> >> lattice:::dotplot.formula
> > function (x, data = NULL, panel = "panel.dotplot", ...)
> > {
> > ocall <- ccall <- match.call()
> > ccall$data <- data
> > ccall$panel <- panel
> > ccall[[1]] <- as.name("bwplot")
> > ans <- eval.parent(ccall)
> > ans$call <- ocall
> > ans
> > }
> >
> >
> > That is, ccall is eval()-ed in the global environment where bwplot is
> > not visible. While this example is somewhat silly, similar things
> > happen when I try to import lattice from another package.
> >
> > Are there any simple alternatives? I tried
> >
> > ccall[[1]] <- as.name("lattice::bwplot")
Seth suggested
ccall[[1]] <- quote(lattice::bwplot)
which makes more sense and seems to work too.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] evaluation in unattached namespace
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> On 4/26/2007 7:39 PM, Deepayan Sarkar wrote:
>> Hi,
>>
>> I recently discovered this buglet in lattice: If lattice is _not_
>> attached, I get
>>
>>> lattice::dotplot(~1:10)
>> Error in eval(expr, envir, enclos) : could not find function "bwplot"
>>
>> This happens because of this:
>>
>>> lattice:::dotplot.formula
>> function (x, data = NULL, panel = "panel.dotplot", ...)
>> {
>> ocall <- ccall <- match.call()
>> ccall$data <- data
>> ccall$panel <- panel
>> ccall[[1]] <- as.name("bwplot")
>> ans <- eval.parent(ccall)
>> ans$call <- ocall
>> ans
>> }
>>
>>
>> That is, ccall is eval()-ed in the global environment where bwplot is
>> not visible. While this example is somewhat silly, similar things
>> happen when I try to import lattice from another package.
>>
>> Are there any simple alternatives? I tried
>>
>> ccall[[1]] <- as.name("lattice::bwplot")
>>
>> but that didn't work either.
>
> One way would be to create a new environment with the caller's
> environment as the parent, and put a copy of bwplot in it, i.e.
> something like the following untested code:
>
> function (x, data = NULL, panel = "panel.dotplot", ...)
> {
> ocall <- ccall <- match.call()
> ccall$data <- data
> ccall$panel <- panel
> ccall[[1]] <- as.name("bwplot")
> evalenv <- new.env(parent = parent.frame())
> assign("bwplot", bwplot, envir=evalenv)
> ans <- eval(ccall, envir=evalenv)
> ans$call <- ocall
> ans
> }
>
quote(lattice::bwplot) also seems to work.
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
