Re: [Rd] Issue when calling deparse(substitute(x)) from C with "anonymous" R vectors ?
Laurent Gautier wrote:
> Dear list,
>
>
> When calling R from C, what appears like a spurious error can be
> triggered during the execution of chisq.test(x, y).
>
> This is happening when the following conditions are met:
>
> - x and y are "anonymous" C-level R vectors (they do not have a symbol),
> but they are protected from garbage collection
>
> - x and y are "not too small" (it was experienced as soon as they are
> longer than 17 elements).
>
>
> The error is
>
> Error in names(dimnames(x)) <- DNAME :
> 'names' attribute [4] must be the same length as the vector [2]
>
> and can be traced to the use of deparse(substitute(x)) and
> deparse(substitute(y)) in the R code.
>
> What seems to be happening is that the deparse(substitute(x)) call
> gives a character vector of length > 1 as soon as x is "not so small".
>
> To demonstrate this, I am using rpy2 (as the problem was found when
> using it
> http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.org&forum_name=rpy-list
>
> ), but it will likely be present in other bridges to R as well.
>
>
> #using R-2.10 and rpy2-2.1.dev
import rpy2.robjects as robjects
>
f = robjects.r('''function(x) return(deparse(substitute(x)))''')
>
tuple(f(robjects.FloatVector(range(17
> ('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
> # length 1
tuple(f(robjects.FloatVector(range(18
> ('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
> # length 2 !!
>
>
> Does it seem to others like an issue present in other bridges as well ?
>
It can be generated from R itself:
> x <- sample(0:1,2000,replace=T)
> y <- sample(0:1,2000,replace=T)
> eval(substitute(chisq.test(x,y),list(x=x,y=y)))
Error in names(dimnames(x)) <- DNAME :
'names' attribute [252] must be the same length as the vector [2]
Looks like nlines=1 is needed in the deparse().
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue when calling deparse(substitute(x)) from C with "anonymous" R vectors ?
This is easy to reproduce in R:
chisq.test(c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010,
1011),
c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011))
The simple answer is: don't do that.
It is unclear what is a reasonable label to give in such a case: maybe
simply 'x' and 'y'?
On Thu, 19 Nov 2009, Laurent Gautier wrote:
Dear list,
When calling R from C, what appears like a spurious error can be triggered
during the execution of chisq.test(x, y).
This is happening when the following conditions are met:
- x and y are "anonymous" C-level R vectors (they do not have a symbol),
but they are protected from garbage collection
- x and y are "not too small" (it was experienced as soon as they are longer
than 17 elements).
The error is
Error in names(dimnames(x)) <- DNAME :
'names' attribute [4] must be the same length as the vector [2]
and can be traced to the use of deparse(substitute(x)) and
deparse(substitute(y)) in the R code.
What seems to be happening is that the deparse(substitute(x)) call
gives a character vector of length > 1 as soon as x is "not so small".
To demonstrate this, I am using rpy2 (as the problem was found when using it
http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.org&forum_name=rpy-list
), but it will likely be present in other bridges to R as well.
#using R-2.10 and rpy2-2.1.dev
import rpy2.robjects as robjects
f = robjects.r('''function(x) return(deparse(substitute(x)))''')
tuple(f(robjects.FloatVector(range(17
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
# length 1
tuple(f(robjects.FloatVector(range(18
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
# length 2 !!
Does it seem to others like an issue present in other bridges as well ?
L.
__
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] bug in '...' of constrOptim (PR#14071)
Hi Ravi,
I just briefly looked at the code (and haven't run it). But it seems
like there is still the underlying problem that '...' argument is sent
to both optim and f. The documentation says that ... arguments are sent
to optim, so at least based on this the ... should only appear in optim.
This seems prefered since you don't need an explicit argument 'hessian'
added; after all the user gets to define f, so the flexibility of ...
there is minimal compared to being able to pass arguments to optim.
Here's the relevant code from what you sent:
a <- optim(theta.old, fun, gradient, control = control,
method = method, hessian=hessian, ...)
r <- a$value
if (is.finite(r) && is.finite(r.old) && abs(r -
r.old)/(outer.eps +
abs(r - r.old)) < outer.eps)
break
theta <- a$par
obj <- f(theta, ...) ###I don't think this should have the ...
Best,
Elizabeth
Ravi Varadhan wrote:
Hi Elizabeth,
I have fixed this problem. See the attached function. There is also
another bug that can create a problem when control$fnscale = -1, i.e. when
the objective function is to be maximized. I have commented this in the
code and have also fixed this problem.
There is a word of caution. Hessian is problematic when the converged
parameter estimate is on the boundary of the feasible region, since the
derivatives are not defined there.
Also, note that the default method is Nelder-Mead. If you want to use
"BFGS", you have to specify the gradient function. I have written an
extension of constrOptim that can use numerical gradients, and can also
handle nonlinear constraints.
Hope this helps,
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor, The Center on Aging and Health
Division of Geriatric Medicine and Gerontology
Johns Hopkins University
Ph: (410) 502-2619
Fax: (410) 614-9625
Email: rvarad...@jhmi.edu
Webpage:
http://www.jhsph.edu/agingandhealth/People/Faculty_personal_pages/Varadhan.h
tml
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of epur...@stat.berkeley.edu
Sent: Wednesday, November 18, 2009 1:10 PM
To: r-de...@stat.math.ethz.ch
Cc: r-b...@r-project.org
Subject: [Rd] bug in '...' of constrOptim (PR#14071)
Dear all,
There appears to be a bug in how constrOptim handles ... arguments that
are suppose to be passed to optim, according to the documentation. This
means you can't get the hessian to be returned, for example (so this is
a real problem, and not just a question of mistaken documentation).
Looking at the code, it appears that a call to the user-defined f
includes the ..., when the ... should only be passed to the optim call.
I get around it by putting a dummy 'hessian=TRUE' argument in my f
function, but this is not how the function should work.
I show the relevant problem in the code, give an example, and also give
my sessionInfo() call below.
Thanks,
Elizabeth
##Copy of the relevant segment of the code of constrOptim and where I
think the problem might be:
for (i in 1L:outer.iterations) {
obj.old <- obj
r.old <- r
theta.old <- theta
fun <- function(theta, ...) { ##this one's okay
R(theta, theta.old, ...)##this one's okay
}
gradient <- function(theta, ...) {##this one's okay
dR(theta, theta.old, ...)##this one's okay
}
a <- optim(theta.old, fun, gradient, control = control,
method = method, ...)##this one's okay
r <- a$value
if (is.finite(r) && is.finite(r.old) && abs(r -
r.old)/(outer.eps +
abs(r - r.old)) < outer.eps)
break
theta <- a$par
obj <- f(theta, ...)##this one's NOT okay
if (obj > obj.old)
break
}
###Here is an example modified from the examples of the help page of
constrOptim:
> fr <- function(x) { ## Rosenbrock Banana function
+ x1 <- x[1]
+ x2 <- x[2]
+ 100 * (x2 - x1 * x1)^2 + (1 - x1)^2
+ }
> grr <- function(x) { ## Gradient of 'fr'
+ x1 <- x[1]
+ x2 <- x[2]
+ c(-400 * x1 * (x2 - x1 * x1) - 2 * (1 - x1),
+200 * (x2 - x1 * x1))
+ }
> constrOptim(c(-1.2,0.9), fr, grr, ui=rbind(c(-1,0),c(0,-1)), ci=c(-1,-1))
$par
[1] 0.761 0.522
$value
[1] 5.708626e-10
$counts
function gradient
61
$convergence
[1] 0
$message
NULL
$outer.iterations
[1] 14
$barrier.value
[1] -0.0001999198
> constrOptim(c(-1.2,0.9), fr, grr, ui=rbind(c(-1,0),c(0,-1)),
ci=c(-1,-1),hessian=TRUE)
Error in f(theta, ...) : unused argument(s) (hessian = TRUE)
#add in a dummy argument to my f function
> fr <- function(x,hessian=TRUE) { ## Rosenbrock Banana function
+ x1 <- x[1]
+ x2 <- x[2]
+ 100 * (
[Rd] Wishlist: In documentation, say that `+.Date`(Date, difftime) should be called directly or remove 'or an object of class "difftime"' (PR#14072)
Full_Name: Suharto Anggono
Version: 2.8.1
OS: Windows
Submission from: (NULL) (125.161.134.206)
About PR#14067, now I understand why (Date + difftime) does not use '+.Date'.
But, before I understand, it was surprising. The surprise is also reflected in
the post "Problem with +(POSIXt, difftime) dispatching -- WAS: How to create
sequence of constant time interval" in R-help 2009-02-17.
This is taken from the documentation of Ops.Date.
Usage
date + x
...
Arguments
datedate objects
...
x a numeric vector (in days) or an object of class "difftime".
...
Reading the documentation above suggests me that I can use (Date + difftime),
which I expect to use date/time arithmetic. PR#13369 also mentions that.
So, the documentation should mention that, to add "Date" with "difftime",
'+.Date' should be called directly, better with example. Alternatively, the
clause 'or an object of class "difftime"' should be removed.
It would be nice if (Date + difftime) could use '+.Date'. But, I think it would
not be easy. One way is making a virtual class that includes "Date", "POSIXct",
and "difftime", say "DateTimeComp", so that the 'class' attribute of
"Date" is c("DateTimeComp", "Date");
"POSIXct" is c("DateTimeComp", "POSIXt", "POSIXct");
"POSIXlt" is c("DateTimeComp", "POSIXt", "POSIXlt");
"difftime" is c("DateTimeComp", "difftime").
Then, define '+.DateTimeComp' or 'Ops.DateTimeComp' that ensures that (Date +
difftime) uses '+.Date'. If it is chosen to define 'Ops.DateTimeComp', the
definition could be like this.
function (e1, e2)
{
if (nargs() == 1)
return(NextMethod(.Generic))
if (.Generic == "+" || .Generic == "-") {
if ((inherits(e1, "Date") && inherits(e2, "POSIXt")) ||
(inherits(e1, "POSIXt") && inherits(e2, "Date")))
stop("binary ", .Generic,
" between Date and POSIXt objects is not defined")
if (inherits(e1, "Date") || inherits(e2, "Date"))
return(do.call(paste(.Generic, "Date", sep = "."), list(e1, e2)))
if (inherits(e1, "POSIXt") || inherits(e2, "POSIXt"))
return(do.call(paste(.Generic, "POSIXt", sep = "."), list(e1, e2)))
}
else {
h1 <- inherits(e1, c("Date", "POSIXt", "difftime"), which = TRUE)
h2 <- inherits(e2, c("Date", "POSIXt", "difftime"), which = TRUE)
if (sum(h1 | h2) > 1)
stop(.Generic, " not defined")
}
NextMethod(.Generic)
}
But, that would require many changes and might break someone's code that access
the 'class' attribute directly.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue when calling deparse(substitute(x)) from C with "anonymous" R vectors ?
Thanks to you and Peter for the quick answer.
I should definitely have tried I R. It just seemed to me so unlikely
that no one ever reported that anonymous vectors would fail with
chisq.test().
Having a label that would be x or y is along the lines of something I
was thinking of, and this not only for chisq.test(). It would be helpful
for functions such as plot() for example.
The idea would be to replace an anonymous object by its variable name,
unless the anonymous variable is coming from a function call.
Example:
foo <- function(x) {
xlabel <- deparse(substitute(x))
# do things
}
foo(y) # xlabel is 'y'
foo(log(y)) # xlabel is 'log(y)'
foo(c(1,2,3)) # xlabel is 'x'
foo(log(c(1,2,3)) # xlabel is 'x'
This would likely require looking at the parse tree for the argument,
and have a switch such as "if any leave is an anonymous object, use the
parameter name".
L.
Prof Brian Ripley wrote:
This is easy to reproduce in R:
chisq.test(c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009,
1010, 1011),
c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011))
The simple answer is: don't do that.
It is unclear what is a reasonable label to give in such a case: maybe
simply 'x' and 'y'?
On Thu, 19 Nov 2009, Laurent Gautier wrote:
Dear list,
When calling R from C, what appears like a spurious error can be
triggered during the execution of chisq.test(x, y).
This is happening when the following conditions are met:
- x and y are "anonymous" C-level R vectors (they do not have a symbol),
but they are protected from garbage collection
- x and y are "not too small" (it was experienced as soon as they are
longer than 17 elements).
The error is
Error in names(dimnames(x)) <- DNAME :
'names' attribute [4] must be the same length as the vector [2]
and can be traced to the use of deparse(substitute(x)) and
deparse(substitute(y)) in the R code.
What seems to be happening is that the deparse(substitute(x)) call
gives a character vector of length > 1 as soon as x is "not so small".
To demonstrate this, I am using rpy2 (as the problem was found when
using it
http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.org&forum_name=rpy-list
), but it will likely be present in other bridges to R as well.
#using R-2.10 and rpy2-2.1.dev
import rpy2.robjects as robjects
f = robjects.r('''function(x) return(deparse(substitute(x)))''')
tuple(f(robjects.FloatVector(range(17
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
# length 1
tuple(f(robjects.FloatVector(range(18
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
# length 2 !!
Does it seem to others like an issue present in other bridges as well ?
L.
__
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] Issue when calling deparse(substitute(x)) from C with "anonymous" R vectors ?
On Thu, 19 Nov 2009, Laurent Gautier wrote:
Thanks to you and Peter for the quick answer.
I should definitely have tried I R. It just seemed to me so unlikely that no
one ever reported that anonymous vectors would fail with chisq.test().
Having a label that would be x or y is along the lines of something I was
thinking of, and this not only for chisq.test(). It would be helpful for
functions such as plot() for example.
But '1:10' is probably what you do want. Changiong the way R does
things in general on the basis of a single example after ca 12 years
would be unwise, not least because the user can change the way he
calls the function to achieve this.
I've chosen simple not to name the dimensions if the deparse is too
long. The description (used by the print method) is trickier, and
results in a long description. Again, if you don't like it, change
the call.
The idea would be to replace an anonymous object by its variable name, unless
the anonymous variable is coming from a function call.
Example:
foo <- function(x) {
xlabel <- deparse(substitute(x))
# do things
}
foo(y) # xlabel is 'y'
foo(log(y)) # xlabel is 'log(y)'
foo(c(1,2,3)) # xlabel is 'x'
foo(log(c(1,2,3)) # xlabel is 'x'
This would likely require looking at the parse tree for the argument, and
have a switch such as "if any leave is an anonymous object, use the parameter
name".
L.
Prof Brian Ripley wrote:
This is easy to reproduce in R:
chisq.test(c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009,
1010, 1011),
c(1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010, 1011))
The simple answer is: don't do that.
It is unclear what is a reasonable label to give in such a case: maybe
simply 'x' and 'y'?
On Thu, 19 Nov 2009, Laurent Gautier wrote:
Dear list,
When calling R from C, what appears like a spurious error can be triggered
during the execution of chisq.test(x, y).
This is happening when the following conditions are met:
- x and y are "anonymous" C-level R vectors (they do not have a symbol),
but they are protected from garbage collection
- x and y are "not too small" (it was experienced as soon as they are
longer than 17 elements).
The error is
Error in names(dimnames(x)) <- DNAME :
'names' attribute [4] must be the same length as the vector [2]
and can be traced to the use of deparse(substitute(x)) and
deparse(substitute(y)) in the R code.
What seems to be happening is that the deparse(substitute(x)) call
gives a character vector of length > 1 as soon as x is "not so small".
To demonstrate this, I am using rpy2 (as the problem was found when using
it
http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.org&forum_name=rpy-list
), but it will likely be present in other bridges to R as well.
#using R-2.10 and rpy2-2.1.dev
import rpy2.robjects as robjects
f = robjects.r('''function(x) return(deparse(substitute(x)))''')
tuple(f(robjects.FloatVector(range(17
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
# length 1
tuple(f(robjects.FloatVector(range(18
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
# length 2 !!
Does it seem to others like an issue present in other bridges as well ?
L.
__
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
[Rd] In the documentation of 'Ops.Date', please remove mention about "difftime", like in the documentation of 'DateTimeClasses' (PR#14072)
I am sorry to reply. But I need to clarify things.=0A=0AFrom searching over=
the internet, I know that, before R 2.5.0, in the documentation of 'DateTi=
meClasses', in 'date + x', in the explanation about 'x', there is also ment=
ion that 'x' can be a 'difftime' object. Now, it has been removed.=0A=0AWhy=
not doing the same in the documentation of 'Ops.Date'? I have read the doc=
umentation carefully. Also, I have just downloaded http://cran.bic.nus.edu.=
sg/src/base-prerelease/R-latest.tar.gz. In the file Ops.Date.Rd, the phrase=
=0A\emph{or} an object of class=0A\code{"\link{difftime}"}=0Ais still t=
here. This is a snapshot from Ops.Date.Rd.=0A=0A\usage{=0A\special{date + x=
}=0A\special{date - x}=0A\special{date1 lop date2}=0A}=0A\arguments{=0A \i=
tem{date}{date objects}=0A \item{date1, date2}{date objects or character v=
ectors. (Character=0Avectors are converted by \code{\link{as.Date}}.)}=
=0A \item{x}{a numeric vector (in days) \emph{or} an object of class=0A =
\code{"\link{difftime}"}.}=0A \item{lop}{One of \code{=3D=3D}, \code{!=3D=
}, \code{<}, \code{<=3D}, \code{>}=0Aor \code{>=3D}.}=0A}=0A=0AThe docu=
mentation says that the usage is=0Adate + x=0ASo,=0Adate + x=0Ashould work.=
=0A=0ASo, in the documentation of 'Ops.Date', in the explanation about argu=
ment 'x', please remove the phrase "or an object of class "difftime".". Tha=
t would be in line with the documentation of 'DateTimeClasses', and at leas=
t saves new users.=0A=0AThank you.=0A=0A=0A New Email addresses availa=
ble on Yahoo!=0AGet the Email name you've always wanted on the new @yma=
il and @rocketmail. =0AHurry before someone else does!=0Ahttp://mail.promot=
ions.yahoo.com/newdomains/aa/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue when calling deparse(substitute(x)) from C with "anonymous" R vectors ?
Can you put together a minimal, self contained example, not requiring an
external system? This has the symptoms of a bug in the external code
(e.g. a missing PROTECT), but it is possible it's a bug in R.
Duncan Murdoch
On 19/11/2009 2:40 AM, Laurent Gautier wrote:
Dear list,
When calling R from C, what appears like a spurious error can be
triggered during the execution of chisq.test(x, y).
This is happening when the following conditions are met:
- x and y are "anonymous" C-level R vectors (they do not have a symbol),
but they are protected from garbage collection
- x and y are "not too small" (it was experienced as soon as they are
longer than 17 elements).
The error is
Error in names(dimnames(x)) <- DNAME :
'names' attribute [4] must be the same length as the vector [2]
and can be traced to the use of deparse(substitute(x)) and
deparse(substitute(y)) in the R code.
What seems to be happening is that the deparse(substitute(x)) call
gives a character vector of length > 1 as soon as x is "not so small".
To demonstrate this, I am using rpy2 (as the problem was found when using it
http://sourceforge.net/mailarchive/forum.php?thread_name=4B043CA1.9050500%40salilab.org&forum_name=rpy-list
), but it will likely be present in other bridges to R as well.
#using R-2.10 and rpy2-2.1.dev
>>> import rpy2.robjects as robjects
>>> f = robjects.r('''function(x) return(deparse(substitute(x)))''')
>>> tuple(f(robjects.FloatVector(range(17
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16)',)
# length 1
>>> tuple(f(robjects.FloatVector(range(18
('c(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17', ')')
# length 2 !!
Does it seem to others like an issue present in other bridges as well ?
L.
__
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] Issue when calling deparse(substitute(x)) from C with "anonymous" R vectors ?
On 19/11/2009 6:32 AM, Duncan Murdoch wrote: Can you put together a minimal, self contained example, not requiring an external system? This has the symptoms of a bug in the external code (e.g. a missing PROTECT), but it is possible it's a bug in R. And I should have read the followups before replying. Sorry for the noise. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] strange crashes caused by 'cairoDevice' and 'tcltk' dialogues
Dear developers I get some strange crashes when 'cairoDevice' and 'tcltk' are both loaded in the same R vanilla session. When executing the following in that order require(relimp) require(cairoDevice) showData (iris) I get a crash with the following message (see R-relimp-cairoDevice.txt): The program 'R' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 2832 error_code 3 request_code 15 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) When I inverse the order of calls, I no longer seem to get issues. (See R-cairoDevice-relimp.txt) require(cairoDevice) require(relimp) showData (iris) Initially I got issues with 'playwith' and 'Rcmdr', but managed to pin down to 'cairoDevice' and 'tcltk' (although it could still be something else). At this point I'm stuck. I tried R -d gdb --vanilla but > require(relimp) Loading required package: relimp Loading Tcl/Tk interface ... [Thread debugging using libthread_db enabled] Cannot find new threads: generic error (gdb) quit I get the same error when trying to load Rcmdr in gdb. Could someone point me to the right direction of investigating these crashes? Thank you Liviu li...@debian-liv:~$ uname -a Linux debian-liv 2.6.30-1-amd64 #1 SMP Sat Aug 15 18:09:19 UTC 2009 x86_64 GNU/Linux li...@debian-liv:~$ cat /etc/apt/sources.list | grep cran2deb deb http://debian.cran.r-project.org/cran2deb/debian-amd64/ testing/ > sessionInfo() R version 2.10.0 (2009-10-26) x86_64-pc-linux-gnu locale: [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_GB.UTF-8 [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] relimp_1.0-1 cairoDevice_2.10 loaded via a namespace (and not attached): [1] tcltk_2.10.0 li...@debian-liv:~$ R --vanilla R version 2.10.0 (2009-10-26) Copyright (C) 2009 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > require(relimp) Loading required package: relimp Loading Tcl/Tk interface ... done > showData (iris) > require(cairoDevice) Loading required package: cairoDevice Warning message: package 'cairoDevice' was built under R version 2.9.0 and help may not work correctly > > showData (iris) > The program 'R' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 2832 error_code 3 request_code 15 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) li...@debian-liv:~$ R --vanilla R version 2.10.0 (2009-10-26) Copyright (C) 2009 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. > require(cairoDevice) Loading required package: cairoDevice Warning message: package 'cairoDevice' was built under R version 2.9.0 and help may not work correctly > require(relimp) Loading required package: relimp Loading Tcl/Tk interface ... done > showData(iris) > sessionInfo() R version 2.10.0 (2009-10-26) x86_64-pc-linux-gnu locale: [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C
Re: [Rd] combine UserDefinedDatabase and regular environments
On Thu, Nov 5, 2009 at 9:58 AM, Romain Francois
wrote:
> Hello,
>
> Is it possible to have the effect of UserDefinedDatabase outside of
> "attached" environments ? Can I disguise an environment of the sys.frames()
> as a UserDefinedDatabase ?
>
> This seems to suggest that it might be possible :
>
> > f <- function(){ e <- environment(); class(e) <- "UserDefinedDatabase";
> ff }
> > f()
>
>
The UserDefinedDatabase support expects an R_ObjectTable C structure
embedded within an externalptr as the HASHTAB of the environment. So it's
really only possible from C.
> *** caught segfault ***
> address (nil), cause 'unknown'
>
> Traceback:
> 1: f()
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
>
>
> At the moment, it seems to be either lookup using UserDefinedDatabase or
> regular lookup. Has anyone tried to combine both ?
>
>
> --
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
> |- http://tr.im/BcPw : celebrating R commit #5
> |- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
> `- http://tr.im/yw8E : New R package : sos
>
> __
> 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] R Usage Statistics
Hi, I got the following comment from the reviewer of a paper (describing an algorithm implemented in R) that I submitted to BMC Bioinformatics: "Finally, which useful for exploratory work and some prototyping, neither R nor S-Plus are appropriate environments for deploying user applications that would receive much use." I can certainly respond by pointing out that CRAN contains more than 2000 packages and Bioconductor contains more than 350. However, does anyone have statistics on how often R (and possibly some R packages) are downloaded, or on how many people actually use R? Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] combine UserDefinedDatabase and regular environments
On 11/19/2009 06:14 PM, Michael Lawrence wrote:
On Thu, Nov 5, 2009 at 9:58 AM, Romain Francois
mailto:romain.franc...@dbmail.com>> wrote:
Hello,
Is it possible to have the effect of UserDefinedDatabase outside of
"attached" environments ? Can I disguise an environment of the
sys.frames() as a UserDefinedDatabase ?
This seems to suggest that it might be possible :
> f <- function(){ e <- environment(); class(e) <-
"UserDefinedDatabase"; ff }
> f()
The UserDefinedDatabase support expects an R_ObjectTable C structure
embedded within an externalptr as the HASHTAB of the environment. So
it's really only possible from C.
Sure. Too bad both environments and user defined database use HASHTAB
with completely different meanings.
What I would want is something like this:
f <- function(){
attachLocally( getSomeUserDefinedDatabaseFromC() )
HELLO
}
and the variable associated with the binding "HELLO" would come
dynamically from the user defined database.
A more concrete example : rJava now has javaImport, that combined with
attach allows dynamic lookup for class names within a set of imported
java package paths:
attach( javaImport( "java.util" ), name = "java:java.util" )
v <- new( Vector )
m <- new( HashMap )
This is nice, but then as usual with attach, you forget to detach, ...
this question is about to find a way to have this instead:
f <- function(){
import( "java.util" )
v <- new( Vector )
v$add( 1 )
v
}
where the "java.util" is no more looked up when f returns.
*** caught segfault ***
address (nil), cause 'unknown'
Traceback:
1: f()
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
At the moment, it seems to be either lookup using
UserDefinedDatabase or regular lookup. Has anyone tried to combine
both ?
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/EAD5 : LondonR slides
|- http://tr.im/BcPw : celebrating R commit #5
`- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Usage Statistics
On Thu, 19 Nov 2009, Kevin R. Coombes wrote: Hi, I got the following comment from the reviewer of a paper (describing an algorithm implemented in R) that I submitted to BMC Bioinformatics: "Finally, which useful for exploratory work and some prototyping, neither R nor S-Plus are appropriate environments for deploying user applications that would receive much use." The reviewer needs to get out more... "Intel Capital has placed the number of R users at 1 million, and Revolution kicks the estimate all the way up to 2 million." from the New York Times Business Innovation Technology Blog http://bits.blogs.nytimes.com/2009/01/08/r-you-ready-for-r/ which follows up on this article http://www.nytimes.com/2009/01/07/technology/business-computing/07program.html in their printed paper. Did the reviewer notice where that article said: "Companies as diverse as Google, Pfizer, Merck, Bank of America, the InterContinental Hotels Group and Shell use it." ??? Yeah, Google and those other companies just don't have much ken for muscular computing. ;-) Maybe you should retool in Visual Basic. HTH, Chuck I can certainly respond by pointing out that CRAN contains more than 2000 packages and Bioconductor contains more than 350. However, does anyone have statistics on how often R (and possibly some R packages) are downloaded, or on how many people actually use R? Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:cbe...@tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Usage Statistics
Hi Kevin, What a surprising comment from a reviewer for BMC Bioinformatics. I just did a PubMed search for "limma" and "aroma.affymetrix", just two methods for which I use R software regularly. "limma" yields 28 hits, several of which are published in BMC Bioinformatics. Bengtsson's aroma.affymetrix paper "Estimation and assessment of raw copy numbers at the single locus level." is already cited by 6 others. It almost seems too easy to work up lists of usage of R packages. Spotfire is an application built around S-Plus that has widespread use in the biopharmaceutical industry at a minimum. Vivek Ranadive's TIBCO company just purchased Insightful, the S-Plus company. (They bought Spotfire previously.) Mr. Ranadive does not spend money on environments that are not appropriate for deploying applications. You could easily cull a list of corporation names from the various R email listservs as well. Press back with the reviewer. Reviewers can learn new things and will respond to arguments with good evidence behind them. Good luck! Steven McKinney From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf Of Kevin R. Coombes [krcoom...@mdacc.tmc.edu] Sent: November 19, 2009 10:47 AM To: r-devel@r-project.org Subject: [Rd] R Usage Statistics Hi, I got the following comment from the reviewer of a paper (describing an algorithm implemented in R) that I submitted to BMC Bioinformatics: "Finally, which useful for exploratory work and some prototyping, neither R nor S-Plus are appropriate environments for deploying user applications that would receive much use." I can certainly respond by pointing out that CRAN contains more than 2000 packages and Bioconductor contains more than 350. However, does anyone have statistics on how often R (and possibly some R packages) are downloaded, or on how many people actually use R? Thanks, Kevin __ 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 Usage Statistics
On Nov 19, 2009, at 4:09 PM, Charles C. Berry wrote: On Thu, 19 Nov 2009, Kevin R. Coombes wrote: Hi, I got the following comment from the reviewer of a paper (describing an algorithm implemented in R) that I submitted to BMC Bioinformatics: "Finally, which useful for exploratory work and some prototyping, neither R nor S-Plus are appropriate environments for deploying user applications that would receive much use." The reviewer needs to get out more... "Intel Capital has placed the number of R users at 1 million, and Revolution kicks the estimate all the way up to 2 million." from the New York Times Business Innovation Technology Blog http://bits.blogs.nytimes.com/2009/01/08/r-you-ready-for-r/ which follows up on this article http://www.nytimes.com/2009/01/07/technology/business-computing/07program.html in their printed paper. Did the reviewer notice where that article said: "Companies as diverse as Google, Pfizer, Merck, Bank of America, the InterContinental Hotels Group and Shell use it." ??? Yeah, Google and those other companies just don't have much ken for muscular computing. ;-) Maybe you should retool in Visual Basic. HTH, Chuck Clearly, a fortunes package nominee... :-) Regards, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Surprising length() of POSIXlt vector (PR#14073)
Arrays of POSIXlt dates always return a length of 9. This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:
strings <- paste('2009-1-', 1:31, sep='')
dates <- strptime(strings, format="%Y-%m-%d")
print(dates)
# [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
# [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
# [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
# [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
# [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
# [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
# [31] "2009-01-31"
print(length(dates))
# [1] 9
str(dates)
# POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
...
print(dates[20])
# [1] "2009-01-20"
print(length(dates[20]))
# [1] 9
I've since realised that POSIXct makes date vectors easier,
but could we also have something like:
length.POSIXlt <- function(x) { length(x$sec) }
in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?
Thanks,
Mark <><
--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status =
major = 2
minor = 10.0
year = 2009
month = 10
day = 26
svn rev = 50208
language = R
version.string = R version 2.10.0 (2009-10-26)
Locale:
C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils,
package:datasets, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
Check the documentation and the archives. Not a bug. b
On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
Arrays of POSIXlt dates always return a length of 9. This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:
strings <- paste('2009-1-', 1:31, sep='')
dates <- strptime(strings, format="%Y-%m-%d")
print(dates)
# [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
"2009-01-05"
# [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
"2009-01-10"
# [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
"2009-01-15"
# [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
"2009-01-20"
# [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
"2009-01-25"
# [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
"2009-01-30"
# [31] "2009-01-31"
print(length(dates))
# [1] 9
str(dates)
# POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
"2009-01-04" ...
print(dates[20])
# [1] "2009-01-20"
print(length(dates[20]))
# [1] 9
I've since realised that POSIXct makes date vectors easier,
but could we also have something like:
length.POSIXlt <- function(x) { length(x$sec) }
in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?
Thanks,
Mark <><
--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status =
major = 2
minor = 10.0
year = 2009
month = 10
day = 26
svn rev = 50208
language = R
version.string = R version 2.10.0 (2009-10-26)
Locale:
C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base
__
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] Surprising length() of POSIXlt vector (PR#14073)
I've checked the archives, and this problem crops up every
few months going back for years.
What I was not able to find was an explanation of why a
function such as
length.POSIXlt <- function(x) { length(x$sec) }
is a Bad Idea, or what it would break. listserv threads
seem to end without presenting an answer. R News 2001
Vol 1/2 discusses that "lots of methods are needed..."
(page 11) but I haven't found discussion of why a length
method isn't feasible.
Can anyone clarify this, or point me at the right
archive or documentation source that discusses why
objects of class POSIXlt always need to return a
length of 9?
Thanks
Steve McKinney
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Benilton Carvalho
> Sent: Thursday, November 19, 2009 4:29 PM
> To: m...@celos.net
> Cc: r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
>
> Check the documentation and the archives. Not a bug. b
>
> On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
>
> > Arrays of POSIXlt dates always return a length of 9. This
> > is correct (they're really lists of vectors of seconds,
> > hours, and so forth), but other methods disguise them as
> > flat vectors, giving superficially surprising behaviour:
> >
> > strings <- paste('2009-1-', 1:31, sep='')
> > dates <- strptime(strings, format="%Y-%m-%d")
> >
> > print(dates)
> > # [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
> > "2009-01-05"
> > # [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
> > "2009-01-10"
> > # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
> > "2009-01-15"
> > # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
> > "2009-01-20"
> > # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
> > "2009-01-25"
> > # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
> > "2009-01-30"
> > # [31] "2009-01-31"
> >
> > print(length(dates))
> > # [1] 9
> >
> > str(dates)
> > # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
> > "2009-01-04" ...
> >
> > print(dates[20])
> > # [1] "2009-01-20"
> >
> > print(length(dates[20]))
> > # [1] 9
> >
> > I've since realised that POSIXct makes date vectors easier,
> > but could we also have something like:
> >
> > length.POSIXlt <- function(x) { length(x$sec) }
> >
> > in datetime.R, to avoid breaking functions (like the
> > str.POSIXt method) which use length() in this way?
> >
> > Thanks,
> > Mark <><
> >
> > --
> >
> > Version:
> > platform = i686-pc-linux-gnu
> > arch = i686
> > os = linux-gnu
> > system = i686, linux-gnu
> > status =
> > major = 2
> > minor = 10.0
> > year = 2009
> > month = 10
> > day = 26
> > svn rev = 50208
> > language = R
> > version.string = R version 2.10.0 (2009-10-26)
> >
> > Locale:
> > C
> >
> > Search Path:
> > .GlobalEnv, package:stats, package:graphics, package:grDevices,
> > package:utils, package:datasets, package:methods, Autoloads,
> > package:base
> >
> > __
> > 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] rounding the time: significant 0 does not appear (PR#14074)
Full_Name: Gustavo Lacerda Version: 2.9.1 OS: Windows Submission from: (NULL) (137.82.157.97) I obtained 'time' by subtracting the results of two calls to sys.Time(). > round(time,0) Time difference of 1 mins > round(time,1) Time difference of 1 mins > round(time,2) Time difference of 1.03 mins > round(time,3) Time difference of 1.032 mins Note that the second command above should return "1.0 mins", rather than "1 min". __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
Steve,
I'm no expert on this, but my understanding is that the choice was to
stick to the definition.
The help file for length() [1] says:
"For vectors (including lists) and factors the length is the number of
elements."
The help file for POSIXlt [2] (for example) says:
"Class ‘"POSIXlt"’ is a named list of vectors representing (...)"
and then lists the 9 elements (sec / min / hour / mday / mon / year /
wday / yday / isdst).
So, by [1] length of POSIXlt objects is 9, because it "is a named list
of vectors representing (...)".
b
On Nov 20, 2009, at 12:19 AM, Steven McKinney wrote:
I've checked the archives, and this problem crops up every
few months going back for years.
What I was not able to find was an explanation of why a
function such as
length.POSIXlt <- function(x) { length(x$sec) }
is a Bad Idea, or what it would break. listserv threads
seem to end without presenting an answer. R News 2001
Vol 1/2 discusses that "lots of methods are needed..."
(page 11) but I haven't found discussion of why a length
method isn't feasible.
Can anyone clarify this, or point me at the right
archive or documentation source that discusses why
objects of class POSIXlt always need to return a
length of 9?
Thanks
Steve McKinney
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of Benilton Carvalho
Sent: Thursday, November 19, 2009 4:29 PM
To: m...@celos.net
Cc: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
Check the documentation and the archives. Not a bug. b
On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
Arrays of POSIXlt dates always return a length of 9. This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:
strings <- paste('2009-1-', 1:31, sep='')
dates <- strptime(strings, format="%Y-%m-%d")
print(dates)
# [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
"2009-01-05"
# [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
"2009-01-10"
# [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
"2009-01-15"
# [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
"2009-01-20"
# [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
"2009-01-25"
# [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
"2009-01-30"
# [31] "2009-01-31"
print(length(dates))
# [1] 9
str(dates)
# POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
"2009-01-04" ...
print(dates[20])
# [1] "2009-01-20"
print(length(dates[20]))
# [1] 9
I've since realised that POSIXct makes date vectors easier,
but could we also have something like:
length.POSIXlt <- function(x) { length(x$sec) }
in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?
Thanks,
Mark <><
--
Version:
platform = i686-pc-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status =
major = 2
minor = 10.0
year = 2009
month = 10
day = 26
svn rev = 50208
language = R
version.string = R version 2.10.0 (2009-10-26)
Locale:
C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:methods, Autoloads,
package:base
__
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
Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
> -Original Message-
> From: Benilton Carvalho [mailto:bcarv...@jhsph.edu]
> Sent: Thursday, November 19, 2009 6:59 PM
> To: Steven McKinney
> Cc: 'm...@celos.net'; 'r-de...@stat.math.ethz.ch'
> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
>
> Steve,
>
> I'm no expert on this, but my understanding is that the choice was to
> stick to the definition.
>
> The help file for length() [1] says:
>
> "For vectors (including lists) and factors the length is the number of
> elements."
>
> The help file for POSIXlt [2] (for example) says:
>
> "Class '"POSIXlt"' is a named list of vectors representing (...)"
>
> and then lists the 9 elements (sec / min / hour / mday / mon / year /
> wday / yday / isdst).
>
> So, by [1] length of POSIXlt objects is 9, because it "is a named list
> of vectors representing (...)".
Thanks, a most sensible description.
After how many bug reports does it qualify for addition to the FAQ?!
Steve McKinney
>
> b
>
> On Nov 20, 2009, at 12:19 AM, Steven McKinney wrote:
>
> >
> > I've checked the archives, and this problem crops up every
> > few months going back for years.
> >
> > What I was not able to find was an explanation of why a
> > function such as
> > length.POSIXlt <- function(x) { length(x$sec) }
> > is a Bad Idea, or what it would break. listserv threads
> > seem to end without presenting an answer. R News 2001
> > Vol 1/2 discusses that "lots of methods are needed..."
> > (page 11) but I haven't found discussion of why a length
> > method isn't feasible.
> >
> > Can anyone clarify this, or point me at the right
> > archive or documentation source that discusses why
> > objects of class POSIXlt always need to return a
> > length of 9?
> >
> > Thanks
> > Steve McKinney
> >
> >
> >> -Original Message-
> >> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> >> project.org] On Behalf Of Benilton Carvalho
> >> Sent: Thursday, November 19, 2009 4:29 PM
> >> To: m...@celos.net
> >> Cc: r-de...@stat.math.ethz.ch
> >> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
> >>
> >> Check the documentation and the archives. Not a bug. b
> >>
> >> On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
> >>
> >>> Arrays of POSIXlt dates always return a length of 9. This
> >>> is correct (they're really lists of vectors of seconds,
> >>> hours, and so forth), but other methods disguise them as
> >>> flat vectors, giving superficially surprising behaviour:
> >>>
> >>> strings <- paste('2009-1-', 1:31, sep='')
> >>> dates <- strptime(strings, format="%Y-%m-%d")
> >>>
> >>> print(dates)
> >>> # [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
> >>> "2009-01-05"
> >>> # [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
> >>> "2009-01-10"
> >>> # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
> >>> "2009-01-15"
> >>> # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
> >>> "2009-01-20"
> >>> # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
> >>> "2009-01-25"
> >>> # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29"
> >>> "2009-01-30"
> >>> # [31] "2009-01-31"
> >>>
> >>> print(length(dates))
> >>> # [1] 9
> >>>
> >>> str(dates)
> >>> # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
> >>> "2009-01-04" ...
> >>>
> >>> print(dates[20])
> >>> # [1] "2009-01-20"
> >>>
> >>> print(length(dates[20]))
> >>> # [1] 9
> >>>
> >>> I've since realised that POSIXct makes date vectors easier,
> >>> but could we also have something like:
> >>>
> >>> length.POSIXlt <- function(x) { length(x$sec) }
> >>>
> >>> in datetime.R, to avoid breaking functions (like the
> >>> str.POSIXt method) which use length() in this way?
> >>>
> >>> Thanks,
> >>> Mark <><
> >>>
> >>> --
> >>>
> >>> Version:
> >>> platform = i686-pc-linux-gnu
> >>> arch = i686
> >>> os = linux-gnu
> >>> system = i686, linux-gnu
> >>> status =
> >>> major = 2
> >>> minor = 10.0
> >>> year = 2009
> >>> month = 10
> >>> day = 26
> >>> svn rev = 50208
> >>> language = R
> >>> version.string = R version 2.10.0 (2009-10-26)
> >>>
> >>> Locale:
> >>> C
> >>>
> >>> Search Path:
> >>> .GlobalEnv, package:stats, package:graphics, package:grDevices,
> >>> package:utils, package:datasets, package:methods, Autoloads,
> >>> package:base
> >>>
> >>> __
> >>> 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
Re: [Rd] rounding the time: significant 0 does not appear (PR#14074)
This is not a bug, and has nothing to do with times. For example: round(1.03,1) [1] 1 Formatting is not the same as rounding. Perhaps you are assuming R formats numbers according to the concept of significant digits, but it doesn't. See the help page for the format function to get started with understanding R's rules for formatting numbers when it displays them. Maybe also some of the introductory R documents available on CRAN. -Don At 3:45 AM +0100 11/20/09, gus1...@optimizelife.com wrote: Full_Name: Gustavo Lacerda Version: 2.9.1 OS: Windows Submission from: (NULL) (137.82.157.97) I obtained 'time' by subtracting the results of two calls to sys.Time(). round(time,0) Time difference of 1 mins round(time,1) Time difference of 1 mins round(time,2) Time difference of 1.03 mins round(time,3) Time difference of 1.032 mins Note that the second command above should return "1.0 mins", rather than "1 min". __ R-devel@r-project.org mailing list https://*stat.ethz.ch/mailman/listinfo/r-devel -- - Don MacQueen Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 m...@llnl.gov __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rounding the time: significant 0 does not appear (PR#14075)
This is not a bug, and has nothing to do with times. For example: > round(1.03,1) [1] 1 Formatting is not the same as rounding. Perhaps you are assuming R formats numbers according to the concept of significant digits, but it doesn't. See the help page for the format function to get started with understanding R's rules for formatting numbers when it displays them. Maybe also some of the introductory R documents available on CRAN. -Don At 3:45 AM +0100 11/20/09, gus1...@optimizelife.com wrote: >Full_Name: Gustavo Lacerda >Version: 2.9.1 >OS: Windows >Submission from: (NULL) (137.82.157.97) > > >I obtained 'time' by subtracting the results of two calls to sys.Time(). > > >> round(time,0) >Time difference of 1 mins >> round(time,1) >Time difference of 1 mins >> round(time,2) >Time difference of 1.03 mins >> round(time,3) >Time difference of 1.032 mins > > >Note that the second command above should return "1.0 mins", rather than "1 >min". > >__ >R-devel@r-project.org mailing list >https://*stat.ethz.ch/mailman/listinfo/r-devel -- - Don MacQueen Lawrence Livermore National Laboratory Livermore, CA, USA 925-423-1062 m...@llnl.gov __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Benilton Carvalho
> Sent: Thursday, November 19, 2009 6:59 PM
> To: Steven McKinney
> Cc: 'm...@celos.net'; 'r-de...@stat.math.ethz.ch'
> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
>
> Steve,
>
> I'm no expert on this, but my understanding is that the
> choice was to
> stick to the definition.
>
> The help file for length() [1] says:
>
> "For vectors (including lists) and factors the length is the
> number of
> elements."
>
> The help file for POSIXlt [2] (for example) says:
>
> "Class '"POSIXlt"' is a named list of vectors representing (...)"
>
> and then lists the 9 elements (sec / min / hour / mday / mon
> / year /
> wday / yday / isdst).
>
> So, by [1] length of POSIXlt objects is 9, because it "is a
> named list
> of vectors representing (...)".
>
> b
Before data.frames existed (c. 1991) the S help files
probably would have described describe 'dim()' in a
similar way for matrices, but it made sense to extend
it and its help file to work on data.frames after they
were invented. Aren't the real questions how much code
would break, how much code would start working, and how
easy or hard would it be for a user to make sense of it
if length(POSIXlt.thing) reported how many dates were
in POSIXlt.thing instead of reporting how many components
were in its representation?
R's rep method for POSIXlt has a length argument that
represents the number of dates, as it must. Its subscript
operator for POSIXlt accepts an index in the range
1:numberOfDates. I.e., lots of its methods act like its
length is the number of dates. However POSIXlt is not
vector-like enough to make a matrix out of or to attach
names to its dates.
I don't think a possibly out-of-date help file
is the definitive answer to the question of whether
or not there should be a length method for POSIXlt.
S+ has a timeDate class (represented as 2 vectors
of integers and some scalar attributes) with a length
method that gives the number of dates. I think the
main problem with the method is that the C-level get_length
function returns a different value than the SV4 method
does.
S+ also has a numRows functions which is documented to
to return the 'number of cases' in a data object, with
methods for lots of classes (vector, matrix, timeSeries,
data.frame, etc.). Users can call that and know it
never represents some accident of implementation as length
might. Then users could abandon the use of length in
favor of numRows except when writing low-level code that
deals with the representation of things. Does R has a
similar high level function? (In that same family of
functions S+ has rowIds, numCols, and colIds to supplant
rownames, ncol, and colnames, respectively.)
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
> On Nov 20, 2009, at 12:19 AM, Steven McKinney wrote:
>
> >
> > I've checked the archives, and this problem crops up every
> > few months going back for years.
> >
> > What I was not able to find was an explanation of why a
> > function such as
> > length.POSIXlt <- function(x) { length(x$sec) }
> > is a Bad Idea, or what it would break. listserv threads
> > seem to end without presenting an answer. R News 2001
> > Vol 1/2 discusses that "lots of methods are needed..."
> > (page 11) but I haven't found discussion of why a length
> > method isn't feasible.
> >
> > Can anyone clarify this, or point me at the right
> > archive or documentation source that discusses why
> > objects of class POSIXlt always need to return a
> > length of 9?
> >
> > Thanks
> > Steve McKinney
> >
> >
> >> -Original Message-
> >> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> >> project.org] On Behalf Of Benilton Carvalho
> >> Sent: Thursday, November 19, 2009 4:29 PM
> >> To: m...@celos.net
> >> Cc: r-de...@stat.math.ethz.ch
> >> Subject: Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)
> >>
> >> Check the documentation and the archives. Not a bug. b
> >>
> >> On Nov 19, 2009, at 8:30 PM, m...@celos.net wrote:
> >>
> >>> Arrays of POSIXlt dates always return a length of 9. This
> >>> is correct (they're really lists of vectors of seconds,
> >>> hours, and so forth), but other methods disguise them as
> >>> flat vectors, giving superficially surprising behaviour:
> >>>
> >>> strings <- paste('2009-1-', 1:31, sep='')
> >>> dates <- strptime(strings, format="%Y-%m-%d")
> >>>
> >>> print(dates)
> >>> # [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04"
> >>> "2009-01-05"
> >>> # [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09"
> >>> "2009-01-10"
> >>> # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14"
> >>> "2009-01-15"
> >>> # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19"
> >>> "2009-01-20"
> >>> # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24"
> >>> "2009-01-25"
> >>> # [26] "2009-01-26" "2009-01-27" "200
[Rd] structure of SYMSXP values.
Hello.
I've now added some support to OCaml-R in order to investigate low-level
structures. See below for an output, concerning 'str'.
But I'm having an issue concerning SEXPs with type SYMSXP.
lazy
{content =
SYMSXP
{pname = lazy {content = NILSXP};
sym_value =
lazy
{content =
SYMSXP
{pname = lazy {content = NILSXP};
sym_value =
lazy
{content =
SYMSXP
{pname = ; sym_value = ; internal = }};
internal = lazy {content = NILSXP}}};
internal = lazy {content = NILSXP}}};
It seems that the sym_value of a SYMSXP is a SYMSXP. But apparently they
seem to be different structures, as the pointers pointing to these
structures (the parent SYMSXP and the child SYMSXP) give different
addresses...
So I'm wondering: what's the structure of SYMSXPs? Is its sym_value
always a SYMSXP? I guess not. When its sym_value is a SYMSXP, is it
pointing to itself?
All the best,
Guillaume Yziquel.
# t;;
- : R.Internal.t =
# unfold 1 t;;
- : unit = ()
# t;;
- : R.Internal.t =
lazy {content = PROMSXP {prom_value = ; expr = ; env = }}
# unfold 2 t;;
- : unit = ()
# t;;
- : R.Internal.t =
lazy
{content =
PROMSXP
{prom_value =
lazy
{content =
SYMSXP {pname = ; sym_value = ; internal = }};
expr =
lazy
{content = LANGSXP {carval = ; cdrval = ; tagval = }};
env = lazy {content = ENVSXP}}}
# unfold 3 t;;
- : unit = ()
# t;;
- : R.Internal.t =
lazy
{content =
PROMSXP
{prom_value =
lazy
{content =
SYMSXP
{pname = lazy {content = NILSXP};
sym_value =
lazy
{content =
SYMSXP {pname = ; sym_value = ; internal = }};
internal = lazy {content = NILSXP}}};
expr =
lazy
{content =
LANGSXP
{carval =
lazy
{content =
SYMSXP {pname = ; sym_value = ; internal = }};
cdrval =
lazy
{content =
LISTSXP {carval = ; cdrval = ; tagval = }};
tagval = lazy {content = NILSXP}}};
env = lazy {content = ENVSXP}}}
# unfold 4 t;;
- : unit = ()
# t;;
- : R.Internal.t =
lazy
{content =
PROMSXP
{prom_value =
lazy
{content =
SYMSXP
{pname = lazy {content = NILSXP};
sym_value =
lazy
{content =
SYMSXP
{pname = lazy {content = NILSXP};
sym_value =
lazy
{content =
SYMSXP
{pname = ; sym_value = ; internal = }};
internal = lazy {content = NILSXP}}};
internal = lazy {content = NILSXP}}};
expr =
lazy
{content =
LANGSXP
{carval =
lazy
{content =
SYMSXP
{pname = lazy {content = CHARSXP};
sym_value = lazy {content = BUILTINSXP};
internal = lazy {content = NILSXP}}};
cdrval =
lazy
{content =
LISTSXP
{carval = lazy {content = INTSXP};
cdrval =
lazy
{content =
LISTSXP
{carval = ; cdrval = ; tagval = }};
tagval = lazy {content = NILSXP}}};
tagval = lazy {content = NILSXP}}};
env = lazy {content = ENVSXP}}}
--
Guillaume Yziquel
http://yziquel.homelinux.org/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
