[Rd] multiple issues with is.unsorted()
Hi,
In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0 or 1 are
sorted: the result will be ‘NA’ for objects of length 2 or more
except for atomic vectors and objects with a class (where the ‘=’
or ‘’ method is used to compare ‘x[i]’ with ‘x[i-1]’ for ‘i’ in
‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type 'raw' in
'isUnsorted'
= Doesn't agree with the doc (unless except for atomic vectors
means it might fail for atomic vectors).
setClass(A, representation(aa=integer))
a - new(A, aa=4:1)
length(a)
[1] 1
is.unsorted(a)
[1] FALSE
Warning message:
In is.na(x) : is.na() applied to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified from a user
point of view. The warning *seems* to suggest that defining an
is.na method for my objects is required for is.unsorted() to
work properly but the doc doesn't make this clear.
Anyway, let's define one, so the warning goes away:
setMethod(is.na, A, function(x) is.na(x@aa))
[1] is.na
Let's define a length method:
setMethod(length, A, function(x) length(x@aa))
[1] length
length(a)
[1] 4
is.unsorted(a)
[1] FALSE
= Is this correct? Hard to know. The doc is not clear about what
should happen for objects of length 2 or more and with a class
but with no = or methods.
Let's define [, =, and :
setMethod([, A, function(x, i, j, ..., drop=TRUE) new(A,
aa=x@aa[i]))
[1] [
rev(a)
An object of class A
Slot aa:
[1] 1 2 3 4
setMethod(=, c(A, A), function(e1, e2) {e1@aa = e2@aa})
[1] =
a = a[3]
[1] TRUE TRUE TRUE FALSE
setMethod(, c(A, A), function(e1, e2) {e1@aa e2@aa})
[1]
a a[3]
[1] TRUE TRUE FALSE FALSE
is.unsorted(a)
[1] FALSE
is.unsorted(rev(a))
[1] FALSE
Still not working as expected. So what's required exactly for making
is.unsorted() work on an object with a class?
BTW, is.unsorted() would be *much* faster, at least on atomic vectors,
without those calls to is.na(). The C code could check for NAs, without
having to do this as a first pass on the full vector like it is the
case with the current implementation. If the vector if unsorted, the
C code is typically able to bail out early so the speed-up will
typically be 1x or more if the vector as millions of elements.
Thanks,
H.
sessionInfo()
R version 3.0.0 (2013-04-03)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.0.0
--
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] is.vector(as.vector(x, m), m) not always TRUE
On Apr 24, 2013, at 01:48 , Hervé Pagès wrote: In the man page for as.vector() (same as man page for vector()): Writers of methods for ‘as.vector’ need to take care to follow the conventions of the default method. In particular • Argument ‘mode’ can be ‘any’, any of the atomic modes, ‘list’, ‘expression’, ‘symbol’, ‘pairlist’ or one of the aliases ‘double’ and ‘name’. • The return value should be of the appropriate mode. For ‘mode = any’ this means an atomic vector or list. • Attributes should be treated appropriately: in particular when the result is an atomic vector there should be no attributes, not even names. • ‘is.vector(as.vector(x, m), m)’ should be true for any mode ‘m’, including the default ‘any’. But: is.vector(as.vector(a, name), name) [1] FALSE Mmmh, the default method itself doesn't seem to follow its own conventions :-/ Looks like there should be a straightforward fix, since is.vector(as.vector(a, name), symbol) [1] TRUE so it is just a matter of implementing name as synomyous with symbol. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] about the 'length' arg of vector()
Hervé Pagès hpa...@fhcrc.org on Tue, 23 Apr 2013 16:20:00 -0700 writes: Hi, In the man page for vector(): length: A non-negative integer specifying the desired length. Double values will be coerced to integer: supplying an argument of length other than one is an error. Since long vectors are supported, it doesn't seem to be true anymore that double values will be coerced to integer: bigraw - vector(raw, 3e9) length(bigraw) [1] 3e+09 storage.mode(length(bigraw)) [1] double At least not always... Indeed. Thank you, Herve! Change committed to the documentation. Martin Maechler, ETH Zurich Thanks, H. -- Hervé Pagès __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] multiple issues with is.unsorted()
Dear Herve,
Hervé Pagès hpa...@fhcrc.org
on Tue, 23 Apr 2013 23:09:21 -0700 writes:
Hi, In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0
or 1 are sorted: the result will be ‘NA’ for objects of
length 2 or more except for atomic vectors and objects
with a class (where the ‘=’ or ‘’ method is used to
compare ‘x[i]’ with ‘x[i-1]’ for ‘i’ in ‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type
'raw' in 'isUnsorted'
= Doesn't agree with the doc (unless except for atomic
vectors means it might fail for atomic vectors).
setClass(A, representation(aa=integer)) a - new(A,
aa=4:1) length(a)
[1] 1
is.unsorted(a)
[1] FALSE Warning message: In is.na(x) : is.na()
applied to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified
from a user point of view. The warning *seems* to suggest
that defining an is.na method for my objects is required
for is.unsorted() to work properly but the doc doesn't
make this clear.
Anyway, let's define one, so the warning goes away:
setMethod(is.na, A, function(x) is.na(x@aa))
[1] is.na
Let's define a length method:
setMethod(length, A, function(x) length(x@aa))
[1] length
length(a)
[1] 4
is.unsorted(a)
[1] FALSE
= Is this correct? Hard to know. The doc is not clear
about what should happen for objects of length 2 or more
and with a class but with no = or methods.
Let's define [, =, and :
setMethod([, A, function(x, i, j, ..., drop=TRUE)
new(A,
aa=x@aa[i])) [1] [
rev(a)
An object of class A Slot aa: [1] 1 2 3 4
setMethod(=, c(A, A), function(e1, e2) {e1@aa =
e2@aa})
[1] =
a = a[3]
[1] TRUE TRUE TRUE FALSE
setMethod(, c(A, A), function(e1, e2) {e1@aa
e2@aa})
[1]
a a[3]
[1] TRUE TRUE FALSE FALSE
is.unsorted(a)
[1] FALSE
is.unsorted(rev(a))
[1] FALSE
Still not working as expected. So what's required exactly
for making is.unsorted() work on an object with a class?
well, read the source code. :-) ;-)
More seriously: On another hidden help page, you find
\code{.gt} and \code{.gtn} are callbacks from \code{\link{rank}} and
\code{\link{is.unsorted}} used for classed objects.
In other words, you'd need do define a method for
.gtn for S4 objects in this case.
yes, indeed I don't know why this is not at all documented.
BTW, is.unsorted() would be *much* faster, at least on
atomic vectors, without those calls to is.na().
Well, in all R versions, apart from R-devel as of yesterday,
the source of is.unsorted() has been
is.unsorted - function(x, na.rm = FALSE, strictly = FALSE)
{
if(is.null(x)) return(FALSE)
if(!na.rm any(is.na(x)))## FIXME is.na(large) is too slow
return(NA)
## else
if(na.rm any(ii - is.na(x)))
x - x[!ii]
.Internal(is.unsorted(x, strictly))
}
so you see the FIXME.
In R-devel (and probably R-patched in the nearer future),
that line is
if(!na.rm anyMissing(x))
so there's no slow code anymore, at least not for the default
case of na.rm = FALSE.
The C code
could check for NAs, without having to do this as a first
pass on the full vector like it is the case with the
current implementation. If the vector if unsorted, the C
code is typically able to bail out early so the speed-up
will typically be 1x or more if the vector as millions
of elements.
you are right (but again: the most important case na.rm=FALSE
case has been solved already I'd say),
but you know well that we do gratefully accept good patches to
the R sources.
Thanks, H.
sessionInfo()
R version 3.0.0 (2013-04-03) Platform:
x86_64-unknown-linux-gnu (64-bit)
locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3]
LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5]
LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7]
LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11]
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages: [1] stats graphics grDevices utils
datasets methods base
loaded via a namespace (and not attached): [1] tools_3.0.0
--
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
Re: [Rd] as.name and namespaces
Here is an example problem: mycall - expression(lm(Y ~ x))[[1]] mycall lm(Y ~ x) newname - stats::lm desiredResult stats::lm(Y ~ x) I've solved the problem in the kludgy way of deparsing, fixing the string and then parsing. I like Duncan's third method, but it seems like it assumes the solution. Moving functions around is unappetizing for my use -- this is for testing and keeping things as faithful to real use is a good thing. Pat On 23/04/2013 21:18, Duncan Murdoch wrote: On 13-04-23 3:51 PM, Patrick Burns wrote: Okay, that's a good reason why it shouldn't. Why it should is that I want to substitute the first element of a call to be a function including the namespace. Three ways: 1. Assign the function from the namespace locally, then call the local one. 2. Import the function in your NAMESPACE (if you know the name in advance). 3. Construct an expression involving ::, and substitute that in. For example: substitute(foo(x), list(foo=quote(baz::bar))) Duncan Murdoch Pat On 23/04/2013 18:32, peter dalgaard wrote: On Apr 23, 2013, at 19:23 , Patrick Burns wrote: 'as.name' doesn't recognize a name with its namespace extension as a name: as.name(lm) lm as.name(stats::lm) `stats::lm` as.name(stats:::lm) `stats:::lm` Is there a reason why it shouldn't? Any reason why it should? :: and ::: are operators. foo$bar is not the same as `foo$bar` either. -- Patrick Burns pbu...@pburns.seanet.com twitter: @burnsstat @portfolioprobe http://www.portfolioprobe.com/blog http://www.burns-stat.com (home of: 'Impatient R' 'The R Inferno' 'Tao Te Programming') __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.name and namespaces
There's also the brute force option: mycall - expression(lm(Y ~ x))[[1]] mycall[[1]] - quote(stats::lm) mycall stats::lm(Y ~ x) eval(mycall, list(Y=rnorm(5),x=1:5)) Call: stats::lm(formula = Y ~ x) Coefficients: (Intercept)x 0.07430 0.02981 On Apr 24, 2013, at 11:29 , Patrick Burns wrote: Here is an example problem: mycall - expression(lm(Y ~ x))[[1]] mycall lm(Y ~ x) newname - stats::lm desiredResult stats::lm(Y ~ x) I've solved the problem in the kludgy way of deparsing, fixing the string and then parsing. I like Duncan's third method, but it seems like it assumes the solution. Moving functions around is unappetizing for my use -- this is for testing and keeping things as faithful to real use is a good thing. Pat -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Solved and Question: Problem with S3 method dispatch and NAMESPACE
On Apr 24, 2013, at 15:59 , Frank Harrell wrote: I found that package quantreg has created a new generic for latex() [I wish it hadn't; this has been a generic in Hmisc for almost 2 decades]. When I require(quantreg) after loading rms, latex(anova.rms object) dispatches latex.default, but everything is fine if I don't load quantreg. rms has import(Hmisc) in NAMESPACE and is loaded before quantreg, hence the conflict. How do I make the generic from Hmisc take precedence? library(quantreg, pos=x) with suitably large x is one idea. Thanks Frank Frank Harrell wrote I have updated the rms package to extensively use NAMESPACE. I cannot get certain S3 methods to dispatch. For example I have in NAMESPACE S3method(anova, rms) S3method(latex, anova.rms) anova.rms produces an object of class anova.rms and there is a latex.anova.rms function in rms. But when I do latex(anova(fit)) I get an invocation of latex.default. I have tried using anova.rms and `anova.rms` in S3method() to no avail. Any help appreciated. I'm using R 2.15.3 Frank - Frank Harrell Department of Biostatistics, Vanderbilt University -- View this message in context: http://r.789695.n4.nabble.com/Problem-with-S3-method-dispatch-and-NAMESPACE-tp4665179p4665216.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 -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Solved and Question: Problem with S3 method dispatch and NAMESPACE
Thank you very much Peter. That did the trick. Frank Peter Dalgaard-2 wrote On Apr 24, 2013, at 15:59 , Frank Harrell wrote: I found that package quantreg has created a new generic for latex() [I wish it hadn't; this has been a generic in Hmisc for almost 2 decades]. When I require(quantreg) after loading rms, latex(anova.rms object) dispatches latex.default, but everything is fine if I don't load quantreg. rms has import(Hmisc) in NAMESPACE and is loaded before quantreg, hence the conflict. How do I make the generic from Hmisc take precedence? library(quantreg, pos=x) with suitably large x is one idea. Thanks Frank Frank Harrell wrote I have updated the rms package to extensively use NAMESPACE. I cannot get certain S3 methods to dispatch. For example I have in NAMESPACE S3method(anova, rms) S3method(latex, anova.rms) anova.rms produces an object of class anova.rms and there is a latex.anova.rms function in rms. But when I do latex(anova(fit)) I get an invocation of latex.default. I have tried using anova.rms and `anova.rms` in S3method() to no avail. Any help appreciated. I'm using R 2.15.3 Frank - Frank Harrell Department of Biostatistics, Vanderbilt University -- View this message in context: http://r.789695.n4.nabble.com/Problem-with-S3-method-dispatch-and-NAMESPACE-tp4665179p4665216.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@ mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes@ Priv: PDalgd@ __ R-devel@ mailing list https://stat.ethz.ch/mailman/listinfo/r-devel - Frank Harrell Department of Biostatistics, Vanderbilt University -- View this message in context: http://r.789695.n4.nabble.com/Problem-with-S3-method-dispatch-and-NAMESPACE-tp4665179p4665226.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] multiple issues with is.unsorted()
More comments .. see inline
Martin Maechler maech...@stat.math.ethz.ch
on Wed, 24 Apr 2013 11:29:39 +0200 writes:
Dear Herve,
Hervé Pagès hpa...@fhcrc.org
on Tue, 23 Apr 2013 23:09:21 -0700 writes:
Hi, In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0 or 1
are sorted: the result will be ‘NA’ for objects of length
2 or more except for atomic vectors and objects with a
class (where the ‘=’ or ‘’ method is used to compare
‘x[i]’ with ‘x[i-1]’ for ‘i’ in ‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type 'raw'
in 'isUnsorted'
= Doesn't agree with the doc (unless except for atomic
vectors means it might fail for atomic vectors).
Well, the doc says about 'x'
| \item{x}{an \R object with a class or a numeric, complex, character or
|logical vector.}
so strictly, is.unsorted() is not to be used on raw vectors.
However I think you have a point:
Raw vectors didn't exist when is.unsorted() was
invented, so where not considered back then.
Originally, raw vectors were really almost only there for
storage, i.e. basically read and write, but now we have
as '' , '=' '==' etc working well for raw() ,
we could allow is.unsorted() to work, too.
Note however, that if you try to sort(raw) you also always get
an error about sort() not being implemented for raw(),...
something we could arguably reconsider, as we admitted the
relational operators ( = == = != ) to work.
{{anyone donating patches to R-devel for sort()ing raw ?}}
setClass(A, representation(aa=integer))
new(A, aa=4:1)
length(a)
[1] 1
is.unsorted(a)
[1] FALSE
Warning message: In is.na(x) : is.na() applied
to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified
from a user point of view. The warning *seems* to suggest
that defining an is.na method for my objects is
required for is.unsorted() to work properly but the doc
doesn't make this clear.
you are right.
We are going to improve on this, at least the documentation.
[.]
The S4 part I've already started addressing in the last reply.
(and we may get back to that.. )
[.]
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] about the 'length' arg of vector()
On 04/24/2013 12:53 AM, Martin Maechler wrote: Hervé Pagès hpa...@fhcrc.org on Tue, 23 Apr 2013 16:20:00 -0700 writes: Hi, In the man page for vector(): length: A non-negative integer specifying the desired length. Double values will be coerced to integer: supplying an argument of length other than one is an error. Since long vectors are supported, it doesn't seem to be true anymore that double values will be coerced to integer: bigraw - vector(raw, 3e9) length(bigraw) [1] 3e+09 storage.mode(length(bigraw)) [1] double At least not always... Indeed. Thank you, Herve! Change committed to the documentation. Great. Thanks! H. Martin Maechler, ETH Zurich Thanks, H. -- Hervé Pagès -- 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] multiple issues with is.unsorted()
Hi Martin,
On 04/24/2013 02:29 AM, Martin Maechler wrote:
Dear Herve,
Hervé Pagès hpa...@fhcrc.org
on Tue, 23 Apr 2013 23:09:21 -0700 writes:
Hi, In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0
or 1 are sorted: the result will be ‘NA’ for objects of
length 2 or more except for atomic vectors and objects
with a class (where the ‘=’ or ‘’ method is used to
compare ‘x[i]’ with ‘x[i-1]’ for ‘i’ in ‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type
'raw' in 'isUnsorted'
= Doesn't agree with the doc (unless except for atomic
vectors means it might fail for atomic vectors).
setClass(A, representation(aa=integer)) a - new(A,
aa=4:1) length(a)
[1] 1
is.unsorted(a)
[1] FALSE Warning message: In is.na(x) : is.na()
applied to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified
from a user point of view. The warning *seems* to suggest
that defining an is.na method for my objects is required
for is.unsorted() to work properly but the doc doesn't
make this clear.
Anyway, let's define one, so the warning goes away:
setMethod(is.na, A, function(x) is.na(x@aa))
[1] is.na
Let's define a length method:
setMethod(length, A, function(x) length(x@aa))
[1] length
length(a)
[1] 4
is.unsorted(a)
[1] FALSE
= Is this correct? Hard to know. The doc is not clear
about what should happen for objects of length 2 or more
and with a class but with no = or methods.
Let's define [, =, and :
setMethod([, A, function(x, i, j, ..., drop=TRUE)
new(A,
aa=x@aa[i])) [1] [
rev(a)
An object of class A Slot aa: [1] 1 2 3 4
setMethod(=, c(A, A), function(e1, e2) {e1@aa =
e2@aa})
[1] =
a = a[3]
[1] TRUE TRUE TRUE FALSE
setMethod(, c(A, A), function(e1, e2) {e1@aa
e2@aa})
[1]
a a[3]
[1] TRUE TRUE FALSE FALSE
is.unsorted(a)
[1] FALSE
is.unsorted(rev(a))
[1] FALSE
Still not working as expected. So what's required exactly
for making is.unsorted() work on an object with a class?
well, read the source code. :-) ;-)
More seriously: On another hidden help page, you find
\code{.gt} and \code{.gtn} are callbacks from \code{\link{rank}} and
\code{\link{is.unsorted}} used for classed objects.
In other words, you'd need do define a method for
.gtn for S4 objects in this case.
Ah, good to know.
yes, indeed I don't know why this is not at all documented.
BTW, is.unsorted() would be *much* faster, at least on
atomic vectors, without those calls to is.na().
Well, in all R versions, apart from R-devel as of yesterday,
the source of is.unsorted() has been
is.unsorted - function(x, na.rm = FALSE, strictly = FALSE)
{
if(is.null(x)) return(FALSE)
if(!na.rm any(is.na(x)))## FIXME is.na(large) is too slow
return(NA)
## else
if(na.rm any(ii - is.na(x)))
x - x[!ii]
.Internal(is.unsorted(x, strictly))
}
so you see the FIXME.
In R-devel (and probably R-patched in the nearer future),
that line is
if(!na.rm anyMissing(x))
so there's no slow code anymore, at least not for the default
case of na.rm = FALSE.
The C code
could check for NAs, without having to do this as a first
pass on the full vector like it is the case with the
current implementation. If the vector if unsorted, the C
code is typically able to bail out early so the speed-up
will typically be 1x or more if the vector as millions
of elements.
you are right (but again: the most important case na.rm=FALSE
case has been solved already I'd say4),
but you know well that we do gratefully accept good patches to
the R sources.
Will do. Thanks!
H.
Thanks, H.
sessionInfo()
R version 3.0.0 (2013-04-03) Platform:
x86_64-unknown-linux-gnu (64-bit)
locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3]
LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5]
LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7]
LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11]
LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages: [1] stats graphics grDevices utils
datasets methods base
loaded via a namespace (and not attached): [1]
Re: [Rd] is.vector(as.vector(x, m), m) not always TRUE
This is now fixed in R-devel (never actually bit anyone, did it?) -pd On Apr 24, 2013, at 08:11 , peter dalgaard wrote: is.vector(as.vector(a, name), name) [1] FALSE Mmmh, the default method itself doesn't seem to follow its own conventions :-/ Looks like there should be a straightforward fix, since is.vector(as.vector(a, name), symbol) [1] TRUE so it is just a matter of implementing name as synomyous with symbol. -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.name and namespaces
Hi Pat,
You could use substitute(),
mycall - quote(list(lm(Y ~ x1), lm(Y ~ x2)))
do.call(substitute, list(mycall, list(lm=quote(stats::lm
list(stats::lm(Y ~ x1), stats::lm(Y ~ x2))
The do.call is necessary because substitute() does not evaluate
its first argument and we want 'mycall' evaluated to become
the call to list(...) before substitute works on it.
substitute replaces all instances of a name in an expression.
bquote lets you be more selective (only names in .() get replaced):
mycall2 - quote(list(lm(Y ~ x1), .(lm)(Y ~ x2)))
do.call(bquote, list(mycall2, list(lm=quote(stats::lm),
list=quote(base::list
list(lm(Y ~ x1), stats::lm(Y ~ x2))
S+'s substitute() has an evaluate=FALSE/TRUE argument to control
whether its first argument is evaluated thus letting you avoid do.call():
S+ mycall - quote(list(lm(Y ~ x1), lm(Y ~ x2)))
S+ substitute(mycall, list(lm=quote(stats::lm)), evaluate=TRUE)
list(stats::lm(Y ~ x1), stats::lm(Y ~ x2))
It is much harder if you want to find and replace expressions more general
than name, e.g., changing stats::lm to lm or log(x+1) to logp1(x) .
package::codetools and package::compiler might help. I have used rapply()
in S+ for this sort of thing but R's rapply() does not work on functions:
S+ f - function(x, y) exp(log(x+1) + log(abs(y)+1) + log(z))
S+ fNew - rapply(f, how=replace, classes=call,
function(e) {
if (identical(e[[1]], quote(log)) is.call(logArg - e[[2]])) {
if (identical(logArg[[1]], quote(`+`)) identical(logArg[[3]],
1)) {
e - call(logp1, logArg[[2]])
}
}
e
})
S+ fNew
function(x, y)
exp(logp1(x) + logp1(abs(y)) + log(z))
The is pretty ugly code but it did help us quickly install optimizations in
a large mass of code.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Patrick Burns
Sent: Wednesday, April 24, 2013 2:30 AM
To: Duncan Murdoch
Cc: r-devel
Subject: Re: [Rd] as.name and namespaces
Here is an example problem:
mycall - expression(lm(Y ~ x))[[1]]
mycall
lm(Y ~ x)
newname - stats::lm
desiredResult
stats::lm(Y ~ x)
I've solved the problem in the kludgy way of
deparsing, fixing the string and then parsing.
I like Duncan's third method, but it seems like
it assumes the solution. Moving functions around
is unappetizing for my use -- this is for testing
and keeping things as faithful to real use is a
good thing.
Pat
On 23/04/2013 21:18, Duncan Murdoch wrote:
On 13-04-23 3:51 PM, Patrick Burns wrote:
Okay, that's a good reason why it shouldn't.
Why it should is that I want to substitute
the first element of a call to be a function
including the namespace.
Three ways:
1. Assign the function from the namespace locally, then call the local
one.
2. Import the function in your NAMESPACE (if you know the name in
advance).
3. Construct an expression involving ::, and substitute that in.
For example:
substitute(foo(x), list(foo=quote(baz::bar)))
Duncan Murdoch
Pat
On 23/04/2013 18:32, peter dalgaard wrote:
On Apr 23, 2013, at 19:23 , Patrick Burns wrote:
'as.name' doesn't recognize a name with
its namespace extension as a name:
as.name(lm)
lm
as.name(stats::lm)
`stats::lm`
as.name(stats:::lm)
`stats:::lm`
Is there a reason why it shouldn't?
Any reason why it should? :: and ::: are operators. foo$bar is not
the same as `foo$bar` either.
--
Patrick Burns
pbu...@pburns.seanet.com
twitter: @burnsstat @portfolioprobe
http://www.portfolioprobe.com/blog
http://www.burns-stat.com
(home of:
'Impatient R'
'The R Inferno'
'Tao Te Programming')
__
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] multiple issues with is.unsorted()
is.unsorted(NA)
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
It depends what you are using the result of is.unsorted() for. If you want
to know if you can save time by not calling x-sort(x) then is.unsorted(NA)
should not say that NA is sorted, as sort(NA) has length 0.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Martin Maechler
Sent: Wednesday, April 24, 2013 8:41 AM
To: Hervé Pagès; r-de...@stat.math.ethz.ch
Cc: Martin Maechler
Subject: Re: [Rd] multiple issues with is.unsorted()
More comments .. see inline
Martin Maechler maech...@stat.math.ethz.ch
on Wed, 24 Apr 2013 11:29:39 +0200 writes:
Dear Herve,
Hervé Pagès hpa...@fhcrc.org
on Tue, 23 Apr 2013 23:09:21 -0700 writes:
Hi, In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0 or 1
are sorted: the result will be ‘NA’ for objects of length
2 or more except for atomic vectors and objects with a
class (where the ‘=’ or ‘’ method is used to compare
‘x[i]’ with ‘x[i-1]’ for ‘i’ in ‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type 'raw'
in 'isUnsorted'
= Doesn't agree with the doc (unless except for atomic
vectors means it might fail for atomic vectors).
Well, the doc says about 'x'
| \item{x}{an \R object with a class or a numeric, complex, character or
|logical vector.}
so strictly, is.unsorted() is not to be used on raw vectors.
However I think you have a point:
Raw vectors didn't exist when is.unsorted() was
invented, so where not considered back then.
Originally, raw vectors were really almost only there for
storage, i.e. basically read and write, but now we have
as '' , '=' '==' etc working well for raw() ,
we could allow is.unsorted() to work, too.
Note however, that if you try to sort(raw) you also always get
an error about sort() not being implemented for raw(),...
something we could arguably reconsider, as we admitted the
relational operators ( = == = != ) to work.
{{anyone donating patches to R-devel for sort()ing raw ?}}
setClass(A, representation(aa=integer))
new(A, aa=4:1)
length(a)
[1] 1
is.unsorted(a)
[1] FALSE
Warning message: In is.na(x) : is.na() applied
to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified
from a user point of view. The warning *seems* to suggest
that defining an is.na method for my objects is
required for is.unsorted() to work properly but the doc
doesn't make this clear.
you are right.
We are going to improve on this, at least the documentation.
[.]
The S4 part I've already started addressing in the last reply.
(and we may get back to that.. )
[.]
Martin
__
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] Verbose output from R CMD check
Many thanks for these comments Simon, that really helps me a lot!
warm regards
David
On 23/04/13 19:30, Simon Urbanek wrote:
On Apr 23, 2013, at 12:43 PM, dpleydell wrote:
Many thanks Simon for your response
Identifying the source of the message is a non-trivial problem because there
are a large number of calls to printf and fprintf etc in several thousands of
lines of code spread over many different *.c files.
There should be none, so apparently you have broken the rules quite a lot ;).
This is not a new rule, R just got better at identifying the transgressions.
Number of lines in your code is quite irrelevant - that's why there is grep and
the search function in editors.
Well, that wouldn't be the first time I've broken rules ;0)
But, how bad could the consequences of my misbehaviour be here? Are we talking
about crashing R or just messing the output a little?
We're not talking life and death here ;) - yes, frustrated users because of
messed up output is the main danger here. Also the behavior changes by GUI and
platform, so throw in inconsistency charge as well.
To be precise, there are two issues: a) the output on stdout/stderr is not
necessarily visible (e.g. the Windows GUI discards it) and it is separate from
the console (e.g. sink() doesn't work on it). More importantly b) it messes up
the use of R in streaming, i.e. uses where you are processing input on stdin
and streaming output on stdout -- it will break the output. This is most
frustrating because the user has no way to control this behavior other than
deleting the offending package.
In Writing R Extensions (current on-line version) the worst they say about
printf is
[QUOTE]
The most useful function for printing from a C routine compiled into R is
Rprintf. This is used in exactly the same way as printf, but is guaranteed to
write to R's output (which might be a GUI console rather than a file, and can
be re-directed by sink).
[UNQUOTE]
and both printf and fprintf are used in section 8.2.2 in the rtest.c example.
Also, the manual does not say explicitly what fprintf should be replaced with.
fprintf() is ok as long as you don't use it with stdout/stderr. You can use it
for files, no problem there.
Come to think of it... my package performs MCMC and uses fprintf to write
samples to an output file. I have noticed that once in each nth blue-moon (for
large n) a single line of output has been dropped or scrambled. More
frequently, the updates of the output file seem to lag behind the progress of
the algorithm's principal loop - for example, file size becomes non-zero much
later than I expect.
Typically, I/O is buffered, so the file is not necessarily updated after you
use fprintf(). By default, it will get updated only after the output buffer has
been filled. You can use fflush() to flush the output buffer to disk
immediately (alternatively you can mark the stream as unbuffered).
I never understood this behaviour or saw how to rectify it. Perhaps replacing fprintf
with something else could guarantee the end of this undesirable behaviour?
Great!
Is there a safe way to re-write the following?
fprintf(fMCMCout, %d %e %e , iteration, posteriorLoglik, parameter);
if (numberRandomEffects 1) {
for (k=0; k numberRandomEffects; k++) {
fprintf(fMCMCout, %e , randomEffects[k]);
}
fprintf(fMCMCout,\n);
This is really a question of 2 parts
1) what is the best replacement of fprintf in the above?
If MCMCout is a file, the above is fine.
and
2) Writing R Extensions says It is wise to write complete lines (including the
\n) before returning to R., so is it legal to defer \n as in the example above?
Yes, sure.
Cheers,
Simon
many thanks
David
--
David Pleydell,
INRA,
UMR-1351 CMAEE,
Domaine Duclos,
Prise D'eau,
97122 Petit Bourg,
Guadeloupe
dpleyd...@antilles.inra.fr
pleyd...@cirad.fr
Tel +33 5 90 25 54 42
Fax +33 5 90 94 03 96
--
David Pleydell,
INRA,
UMR-1351 CMAEE,
Domaine Duclos,
Prise D'eau,
97122 Petit Bourg,
Guadeloupe
dpleyd...@antilles.inra.fr
pleyd...@cirad.fr
Tel +33 5 90 25 54 42
Fax +33 5 90 94 03 96
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] multiple issues with is.unsorted()
Hi,
On 04/24/2013 09:27 AM, William Dunlap wrote:
is.unsorted(NA)
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
It depends what you are using the result of is.unsorted() for. If you want
to know if you can save time by not calling x-sort(x) then is.unsorted(NA)
should not say that NA is sorted, as sort(NA) has length 0.
Glad you mention this. This is related but actually a different issue
which is that by default is.unsorted() and sort() don't treat NAs
consistently: the former keeps them, the latter removes them. So if
you want to use is.unsorted() for deciding whether or not you're going
to call sort() (without specifying 'na.last'), you should do
'is.unsorted( , na.rm=TRUE)'.
This is why IMO 'is.unsorted( , na.rm=TRUE)' is an important use case
and should be as fast as possible.
If you want to keep NAs, you'll have to sort 'x' with either
na.last=TRUE or na.last=FALSE. So it makes a lot of sense that
is.unsorted(x) returns FALSE if x is a single NA, because, in that
case, 'x' doesn't need to be sorted.
Cheers,
H.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Martin Maechler
Sent: Wednesday, April 24, 2013 8:41 AM
To: Hervé Pagès; r-de...@stat.math.ethz.ch
Cc: Martin Maechler
Subject: Re: [Rd] multiple issues with is.unsorted()
More comments .. see inline
Martin Maechler maech...@stat.math.ethz.ch
on Wed, 24 Apr 2013 11:29:39 +0200 writes:
Dear Herve,
Hervé Pagès hpa...@fhcrc.org
on Tue, 23 Apr 2013 23:09:21 -0700 writes:
Hi, In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0 or 1
are sorted: the result will be ‘NA’ for objects of length
2 or more except for atomic vectors and objects with a
class (where the ‘=’ or ‘’ method is used to compare
‘x[i]’ with ‘x[i-1]’ for ‘i’ in ‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type 'raw'
in 'isUnsorted'
= Doesn't agree with the doc (unless except for atomic
vectors means it might fail for atomic vectors).
Well, the doc says about 'x'
| \item{x}{an \R object with a class or a numeric, complex, character or
|logical vector.}
so strictly, is.unsorted() is not to be used on raw vectors.
However I think you have a point:
Raw vectors didn't exist when is.unsorted() was
invented, so where not considered back then.
Originally, raw vectors were really almost only there for
storage, i.e. basically read and write, but now we have
as '' , '=' '==' etc working well for raw() ,
we could allow is.unsorted() to work, too.
Note however, that if you try to sort(raw) you also always get
an error about sort() not being implemented for raw(),...
something we could arguably reconsider, as we admitted the
relational operators ( = == = != ) to work.
{{anyone donating patches to R-devel for sort()ing raw ?}}
setClass(A, representation(aa=integer))
new(A, aa=4:1)
length(a)
[1] 1
is.unsorted(a)
[1] FALSE
Warning message: In is.na(x) : is.na() applied
to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified
from a user point of view. The warning *seems* to suggest
that defining an is.na method for my objects is
required for is.unsorted() to work properly but the doc
doesn't make this clear.
you are right.
We are going to improve on this, at least the documentation.
[.]
The S4 part I've already started addressing in the last reply.
(and we may get back to that.. )
[.]
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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] multiple issues with is.unsorted()
On 04/24/2013 12:00 PM, Hervé Pagès wrote:
Hi,
On 04/24/2013 09:27 AM, William Dunlap wrote:
is.unsorted(NA)
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
It depends what you are using the result of is.unsorted() for. If you
want
to know if you can save time by not calling x-sort(x) then
is.unsorted(NA)
should not say that NA is sorted, as sort(NA) has length 0.
Glad you mention this. This is related but actually a different issue
which is that by default is.unsorted() and sort() don't treat NAs
consistently: the former keeps them, the latter removes them. So if
you want to use is.unsorted() for deciding whether or not you're going
to call sort() (without specifying 'na.last'), you should do
'is.unsorted( , na.rm=TRUE)'.
This is why IMO 'is.unsorted( , na.rm=TRUE)' is an important use case
and should be as fast as possible.
If you want to keep NAs, you'll have to sort 'x' with either
na.last=TRUE or na.last=FALSE. So it makes a lot of sense that
is.unsorted(x) returns FALSE if x is a single NA, because, in that
case, 'x' doesn't need to be sorted.
And I should add that, for that use case (want to keep NAs when
sorting), is.unsorted() is totally useless anyway because it will
return NA if 'x' has length = 2 and contains NAs :-/
Cheers,
H.
Cheers,
H.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf
Of Martin Maechler
Sent: Wednesday, April 24, 2013 8:41 AM
To: Hervé Pagès; r-de...@stat.math.ethz.ch
Cc: Martin Maechler
Subject: Re: [Rd] multiple issues with is.unsorted()
More comments .. see inline
Martin Maechler maech...@stat.math.ethz.ch
on Wed, 24 Apr 2013 11:29:39 +0200 writes:
Dear Herve,
Hervé Pagès hpa...@fhcrc.org
on Tue, 23 Apr 2013 23:09:21 -0700 writes:
Hi, In the man page for is.unsorted():
Value:
A length-one logical value. All objects of length 0 or 1
are sorted: the result will be ‘NA’ for objects of length
2 or more except for atomic vectors and objects with a
class (where the ‘=’ or ‘’ method is used to compare
‘x[i]’ with ‘x[i-1]’ for ‘i’ in ‘2:length(x)’).
This contains many incorrect statements:
length(NA)
[1] 1
is.unsorted(NA)
[1] NA
length(list(NA))
[1] 1
is.unsorted(list(NA))
[1] NA
= Contradicts all objects of length 0 or 1 are sorted.
Ok. I really think we should change the above.
If NA is for a missing number, it still cannot be unsorted if it
is of length one.
-- the above will give FALSE real soon now.
is.unsorted(raw(2))
Error in is.unsorted(raw(2)) : unimplemented type 'raw'
in 'isUnsorted'
= Doesn't agree with the doc (unless except for atomic
vectors means it might fail for atomic vectors).
Well, the doc says about 'x'
| \item{x}{an \R object with a class or a numeric, complex,
character or
|logical vector.}
so strictly, is.unsorted() is not to be used on raw vectors.
However I think you have a point:
Raw vectors didn't exist when is.unsorted() was
invented, so where not considered back then.
Originally, raw vectors were really almost only there for
storage, i.e. basically read and write, but now we have
as '' , '=' '==' etc working well for raw() ,
we could allow is.unsorted() to work, too.
Note however, that if you try to sort(raw) you also always get
an error about sort() not being implemented for raw(),...
something we could arguably reconsider, as we admitted the
relational operators ( = == = != ) to work.
{{anyone donating patches to R-devel for sort()ing raw ?}}
setClass(A, representation(aa=integer))
new(A, aa=4:1)
length(a)
[1] 1
is.unsorted(a)
[1] FALSE
Warning message: In is.na(x) : is.na() applied
to non-(list or vector) of type 'S4'
= Ok, but it's arguable the warning is useful/justified
from a user point of view. The warning *seems* to suggest
that defining an is.na method for my objects is
required for is.unsorted() to work properly but the doc
doesn't make this clear.
you are right.
We are going to improve on this, at least the documentation.
[.]
The S4 part I've already started addressing in the last reply.
(and we may get back to that.. )
[.]
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
Re: [Rd] is.vector(as.vector(x, m), m) not always TRUE
On 04/24/2013 09:02 AM, peter dalgaard wrote: This is now fixed in R-devel (never actually bit anyone, did it?) Thanks for fixing... before someone gets bitten :-) as.vector() just made it into the BiocGenerics package, and the man page for BiocGenerics::as.vector redirects the reader to the man page for base::as.vector for the conventions that writers of methods for as.vector should follow. Having base::as.vector actually follow those conventions increases the chances that writers of as.vector methods will follow them too, which is good. Cheers, H. -pd On Apr 24, 2013, at 08:11 , peter dalgaard wrote: is.vector(as.vector(a, name), name) [1] FALSE Mmmh, the default method itself doesn't seem to follow its own conventions :-/ Looks like there should be a straightforward fix, since is.vector(as.vector(a, name), symbol) [1] TRUE so it is just a matter of implementing name as synomyous with symbol. -- 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] Patch proposal for R style consistency (concerning deparse.c)
On 13-04-24 8:08 PM, Hervé Pagès wrote:
On 04/18/2013 11:41 AM, Yihui Xie wrote:
I second the change of } else {.
Me too. Note that print.function() will screw it only if you use
useSource=FALSE:
print.function(foo3, useSource=FALSE)
function ()
{
if (FALSE) {
letters
}
else {
LETTERS
}
}
Otherwise, everything is fine:
print.function(foo3)
function()
{
if (FALSE) {
letters # some comment
} else {
LETTERS
}
}
I can't see of any reason why useSource=FALSE would screw my nicely
formatted 'if' statement though.
You asked it to reformat it, because you didn't like your original
formatting. Otherwise you wouldn't have said useSource=FALSE.
This formatting is ugly, unnecessarily
uses 1 more line, and the 'if' statement cannot be copy/pasted into an
interactive session anymore. So, in a way, you could even consider
this is invalid code.
That's nonsense.
Duncan Murdoch
Thanks,
H.
Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Thu, Apr 18, 2013 at 11:16 AM, Paul Johnson pauljoh...@gmail.com wrote:
OK, I concede that.
Now, how about } else {
I will provide patch that does only that change.
?
On Thu, Apr 18, 2013 at 3:05 AM, peter dalgaard pda...@gmail.com wrote:
On Apr 18, 2013, at 05:39 , Paul Johnson wrote:
2 3. I want to omit space after if and for. Since if and for are
functions in R, not keywords, I suggest that there should not be a
space before the opening parentheses.
Wrong. They are part of language constructs (and they _are_ keywords, not
names, that's why ?for won't work). The function calls are `if`(fee, {foo},
{fie}) and something rebarbative for `for`().
Besides, both constructs are harder to read without the spaces.
--
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
__
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] Error Message while creation Package
Hello Guys, I wanted to build a new R package from the R code. I installed all the required software and made all the path settings. When i tried running, cmd RCMD check SamplePackageName while Checking R code for possible errors i have encountered a note saying: waning in png(file=Output_FileName, width=840, height=480, unit=px): partial argument match of 'file' to 'filename'. I don't have any idea of what this warning is. Any help is really appreciated. Thanks -- View this message in context: http://r.789695.n4.nabble.com/Error-Message-while-creation-Package-tp4665345.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] Error Message while Package creation
Hello Guys, I wanted to build a new R package from the R code. I installed all the required software and made all the path settings. When i tried running, cmd RCMD check SamplePackageName while Checking R code for possible errors i have encountered a note saying: waning in png(file=Output_FileName, width=840, height=480, unit=px): partial argument match of 'file' to 'filename'. I don't have any idea of what this warning is. Any help is really appreciated. Thanks -- View this message in context: http://r.789695.n4.nabble.com/Error-Message-while-Package-creation-tp4665346.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] Error Message while Package creation
On 25-04-2013, at 07:21, Crish.. krishnaiah...@gmail.com wrote: Hello Guys, I wanted to build a new R package from the R code. I installed all the required software and made all the path settings. When i tried running, cmd RCMD check SamplePackageName while Checking R code for possible errors i have encountered a note saying: waning in png(file=Output_FileName, width=840, height=480, unit=px): partial argument match of 'file' to 'filename'. I don't have any idea of what this warning is. Any help is really appreciated. It is exactly what it says. The relevant argument has name filename and not file (an abbreviation). Use filename=Output_FileName. Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
