[Rd] R4.1: seq.POSIXt, tz="AEST" (PR#9572)
Times from seq.POSIXt come out wrong in AEST timezone around Feb 29 every
leap year before 1970 (on Windows XP).
According to help(DateTimeClasses), this is handled by "our own C code".
> x <- as.POSIXct("1968-02-27") # tz="AEST"
> x.gmt <- as.POSIXct("1968-02-27", tz="GMT")
> data.frame(
GMT=seq(x.gmt, by="day", length=8),
byday=seq(x, by="day", length=8),
byDST=seq(x, by="DSTday", length=8))
GMT byday byDST
1 1968-02-27 1968-02-27 1968-02-27
2 1968-02-28 1968-02-28 1968-02-28
3 1968-02-29 1968-03-01 1968-03-02
4 1968-03-01 1968-03-02 1968-03-02
5 1968-03-02 1968-03-02 1968-03-02
6 1968-03-03 1968-03-03 1968-03-03
7 1968-03-04 1968-03-04 1968-03-04
8 1968-03-05 1968-03-05 1968-03-05
> R.version
_
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 4.1
year 2006
month 12
day 18
svn rev40228
language R
version.string R version 2.4.1 (2006-12-18)
--
Felix Andrews / $B0BJ!N)(B
Beijing Bag, Locked Bag 40, Kingston ACT 2604
Building 48A, Linnaeus Way, The Australian National University ACT 0200
Australia
http://www.neurofractal.org/felix/
mailto:[EMAIL PROTECTED]
voice:+86_1051404394 (in China)
mobile:+86_13522529265 (in China)
mobile:+61_410400963 (in Australia)
xmpp:[EMAIL PROTECTED]
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R4.1: seq.POSIXt, tz="AEST" (PR#9572)
--=_Part_63767_16761935.1174312715444
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I am sorry, "AEST" was wrong. I can't work out what timezone code it is, but
my default timezone here in eastern australia prints as:
> as.POSIXct("1970-01-01", tz="")
[1] "1970-01-01 AUS Eastern Daylight Time"
and that is the one that has repeated dates before 1970.
But I take your point that it is fundamentally a problem with Windows.
--Felix
On 3/19/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>
> Hmm, AEST is not a valid time zone on Windows.
> See ?as.POSIXlt for one of several places where this is documented.
>
> But in any case, the underlying problem is in the OS, and we only try to
> work around it to the best of our knowledge (and that excludes
> undocumented time zones).
>
>
> On Mon, 19 Mar 2007, [EMAIL PROTECTED] wrote:
>
> > Times from seq.POSIXt come out wrong in AEST timezone around Feb 29
> every
> > leap year before 1970 (on Windows XP).
> >
> > According to help(DateTimeClasses), this is handled by "our own C code".
> >
> >> x <- as.POSIXct("1968-02-27") # tz="AEST"
> >> x.gmt <- as.POSIXct("1968-02-27", tz="GMT")
> >> data.frame(
> > GMT=seq(x.gmt, by="day", length=8),
> > byday=seq(x, by="day", length=8),
> > byDST=seq(x, by="DSTday", length=8))
> > GMT byday byDST
> > 1 1968-02-27 1968-02-27 1968-02-27
> > 2 1968-02-28 1968-02-28 1968-02-28
> > 3 1968-02-29 1968-03-01 1968-03-02
> > 4 1968-03-01 1968-03-02 1968-03-02
> > 5 1968-03-02 1968-03-02 1968-03-02
> > 6 1968-03-03 1968-03-03 1968-03-03
> > 7 1968-03-04 1968-03-04 1968-03-04
> > 8 1968-03-05 1968-03-05 1968-03-05
> >
> >> R.version
> > _
> > platform i386-pc-mingw32
> > arch i386
> > os mingw32
> > system i386, mingw32
> > status
> > major 2
> > minor 4.1
> > year 2006
> > month 12
> > day18
> > svn rev40228
> > language R
> > version.string R version 2.4.1 (2006-12-18)
> >
> >
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
--=_Part_63767_16761935.1174312715444
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
I am sorry, "AEST" was wrong. I can't work out what timezone code
it is, but my default timezone here in eastern australia prints as:>
as.POSIXct("1970-01-01", tz="")[1] "1970-01-01 AUS
Eastern Daylight Time"
and that is the one that has repeated dates before 1970.But I
take your point that it is fundamentally a problem with
Windows.--FelixOn 3/19/07,
Prof Brian Ripley <mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]> wrote:
Hmm, AEST is not a valid time zone on Windows.See ?as.POSIXlt for one of
several places where this is documented.But in any case, the underlying
problem is in the OS, and we only try towork around it to the best of our
knowledge (and that excludes
undocumented time zones).On Mon, 19 Mar 2007, mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED] wrote:> Times
from seq.POSIXt come out wrong in AEST timezone around Feb 29 every>
leap year before 1970 (on Windows XP).
>> According to help(DateTimeClasses), this is handled by
"our own C code".>>> x <-
as.POSIXct("1968-02-27") # tz="AEST">> x.gmt
<- as.POSIXct("1968-02-27", tz="GMT")
>> data.frame(> GMT=seq(x.gmt,
by="day", length=8),> byday=seq(x,
by="day", length=8),> byDST=seq(x,
by="DSTday",
length=8))>
GMT byday byDST
> 1 1968-02-27 1968-02-27 1968-02-27> 2 1968-02-28 1968-02-28
1968-02-28> 3 1968-02-29 1968-03-01 1968-03-02> 4 1968-03-01
1968-03-02 1968-03-02> 5 1968-03-02 1968-03-02 1968-03-02> 6
1968-03-03 1968-03-03 1968-03-03
> 7 1968-03-04 1968-03-04 1968-03-04> 8 1968-03-05 1968-03-05
1968-03-05>>>
R.version>
_> platform i386-pc-mingw32>
arch i386>
os
mingw32
> system i386,
mingw32> status>
major
[Rd] bquote(function(x,y) T) (PR#9602)
> quote(function(x, y) T) function(x, y) T > bquote(function(x, y) T) function(, y) T > eval(.Last.value) Error in eval(expr, envir, enclos) : invalid formal argument list for "function" > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 4.1 year 2006 month 12 day18 svn rev40228 language R version.string R version 2.4.1 (2006-12-18) -- Felix Andrews / $B0BJ!N)(B PhD candidate, The Fenner School of Environment and Society The Australian National University (Building 48A), ACT 0200 Beijing Bag, Locked Bag 40, Kingston ACT 2604 http://www.neurofractal.org/felix/ voice:+86_1051404394 (in China) mobile:+86_13522529265 (in China) mobile:+61_410400963 (in Australia) xmpp:[EMAIL PROTECTED] 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] compairing doubles
Dear all,
I a bit unsure, whether this qualifies as a bug, but it is definitly a strange
behaviour. That why I wanted to discuss it.
With the following function, I want to test for evenly space numbers, starting
from anywhere.
.is_continous_evenly_spaced <- function(n){
if(length(n) < 2) return(FALSE)
n <- n[order(n)]
n <- n - min(n)
step <- n[2] - n[1]
test <- seq(from = min(n), to = max(n), by = step)
if(length(n) == length(test) &&
all(n == test)){
return(TRUE)
}
return(FALSE)
}
> .is_continous_evenly_spaced(c(1,2,3,4))
[1] TRUE
> .is_continous_evenly_spaced(c(1,3,4,5))
[1] FALSE
> .is_continous_evenly_spaced(c(1,1.1,1.2,1.3))
[1] FALSE
I expect the result for 1 and 2, but not for 3. Upon Investigation it turns
out, that n == test is TRUE for every pair, but not for the pair of 0.2.
The types reported are always double, however n[2] == 0.1 reports FALSE as well.
The whole problem is solved by switching from all(n == test) to
all(as.character(n) == as.character(test)). However that is weird, isn�t it?
Does this work as intended? Thanks for any help, advise and suggestions in
advance.
Best regards,
Felix
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Precompiled vignette on CRAN
Hello, my package passes R CMD check without any warnings on my local machine (Mac OS), as well as on Uwe Ligges' Winbuilder. On RForge, however, we sometimes run into problems building the Sweave vignettes. Now here's my question: is it necessary for a CRAN submission that the Sweave vignettes can be compiled on CRAN, or is it possible to provide the (locally compiled) pdf vignette to be included in the package? Best, Felix __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Precompiled vignette on CRAN
Thanks for your help on this topic.
In fact, one of the vignettes needs hours to run some simulations; hence I'm
going to provide the pdf for CRAN.
>
> * - which reminds me -- what is the correct place to list vignette
> dependencies? "Suggests:" ?
I now added a
%\VignetteDepends{lme4}
statement to the vignette.
Best,
Felix
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD INSTALL warning for S4 replacement functions on R 4.1.0-alpha
Hi all, Since R 4.1, R CMD INSTALL throws warning during building the man pages, when installing from source. We noticed this first on Windows for man pages involving S4 replacement function: * http://bioconductor.org/checkResults/devel/bioc-LATEST/Modstrings/riesling1-checksrc.html * http://bioconductor.org/checkResults/devel/bioc-LATEST/GenomicAlignments/riesling1-checksrc.html However, it's also showing up on linux with a slight twist (file not found instead of invalid argument) for other functions: * https://cran.r-project.org/web/checks/check_results_Matrix.html (right at the end) >From the messages and the involved offending filenames, we hypothesize that >this is triggered by invalid filenames specific to the OS. Please note, that the warning is not issued during R CMD CHECK for a given package. Can anyone comment on this? Is more information needed? If it is a bug, I am happy to post on the bug tracker. Thanks for any advice. Best regards, Felix [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Snippets from other packages/ License
Hello, I want to use a function from another package (which is GPL>=3), about 20 lines of code, in my own package. I somewhat hesitate to depend on the entire package just for this single function, but of course I want to credit the original authors. What would be the best way to do that? Where should I put that credit? Or should I proceed completely different? Best, Felix __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Snippets from other packages/ License
Thanks Brian and Hadley, these all seem to be reasonable approaches! (For the current package I think I'll depend on the other one, but it's good to know how to proceed for future situations …). Felix Am 14.03.2013 um 16:52 schrieb Hadley Wickham : >> If you wish to fork the original code and include the code directly in >> your package, then your package will also need to be GPL>=3, you will need >> to list the authors of that code as Contributors in your DESCRIPTION file, >> and I would strongly recommend that you place this code in a separate .R >> file in your package, with a separate Copyright and License comment block in >> that separate file stating the origins and license for this code snippet. > > Another option is to email the original author and ask if they'd be > willing to license the code to you under whatever license your package > currently uses. > > Hadley > > -- > Chief Scientist, RStudio > http://had.co.nz/ > > __ > 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] Suppress specific warnings
Hello, is there a convenient way to suppress only *specific* warnings? (I know about ?suppressWarnings) I depend on another package, from which I want to suppress only some warnings, but not others. Felix __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rowSums, rowMean and rowCumSums?
Hi, you can compute cumsums for each row with t(apply(x, 1, cumsum)) As this is a simple, direct implementation, I see no reason to make it a named function. Cheers -Felix 2009/7/31 Christophe Dutang : > Dear list, > > Don't you think it could be useful to have in R base a function > rowCumSums, that compute cumulative sums for each row of a matrix? > > My implementation of rowCumSums is > > rowCumSums <- function(x) t(mapply(function(row)cumsum(x[row,]), > 1:NROW(x))) > > I'm sure it can be improved to have other arguments like na.rm or dims. > > Is there any hope to have this function in R? > > Christophe > > -- > Christophe Dutang > Ph.D. student at ISFA, Lyon, France > website: http://dutangc.free.fr > > > > > > > > [[alternative HTML version deleted]] > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 1670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] model.matrix evaluation challenges
how about... nrow(with(cc, model.matrix(params, data=environment( cheers -Felix 2009/8/10 Ben Bolker : > I am having difficulty with evaluation/environment construction > for a formula to be evaluated by model.matrix(). Basically, I > want to construct a model matrix that first looks in "newdata" > for the values of the model parameters, then in "obj...@data". > Here's what I've tried: > > 1. model.matrix(~f,data=c(newdata,obj...@data)) -- fails because > something (terms()?) within model.matrix() tries to coerce "data" > to a data frame -- but newdata and obj...@data have different > numbers of rows. > > 2. with(c(newdata,obj...@data),model.matrix(~f)) works -- > BUT not when ~f is assigned to another object (as it will be > when it is being dug out of a previously fit model). > > 3. If "f" exists as a column within newdata and/or obj...@data, > but the formula is assigned to another object (see below), then > with(c(newdata,obj...@data),model.matrix(z)) fails -- because > model.matrix() is explicitly evaluating the variables in the formula > in the environment of z (i.e., ignoring the first argument of "with" ...) > > > Any advice on how to solve this without making a bigger mess? > > sincerely > Ben Bolker > > > ## set up a data frame for prediction > > set.seed(1001) > f = factor(rep(letters[1:4],each=20)) > x = runif(80) > u = rnorm(4) > y = rnorm(80,mean=2+x*(3+u[f]),sd=0.1) > dat = data.frame(f,x,y) > > ## fit a model ... could easily do by lm() but want to > ## demonstrate the problem > > library(bbmle) > m1 = mle2(y~dnorm(a+b*x,sd=exp(logs)),parameters=list(b~f),data=dat, > start=list(a=0,b=2,logs=-3)) > > ## data frame for prediction > pp0 = expand.grid(x=seq(0,1,length=11), > f=levels(dat$f)) > > ## combine frame and model data: have to keep the model data > ## around, because it contain other information needed for > ## prediction. > > cc = c(pp0,m...@data) > try(mm <- model.matrix(~f,cc)) ## fails -- different number of rows > ## (at some point R tries to coerce cc to a data frame) > nrow(with(cc,model.matrix(~f))) ## works ... but ... > > ## here's what happens within predict.mle2() > ## extract information about parameter models > params <- eval(m...@call$parameters) > params <- params[[1]] > params[[2]] <- NULL > > nrow(with(cc,model.matrix(params))) > rm(f) > ## object "f" not found -- because model.matrix > ## evaluates in the parent environment of params ... > try(nrow(with(cc,model.matrix(params > > > > -- > Ben Bolker > Associate professor, Biology Dep't, Univ. of Florida > bol...@ufl.edu / www.zoology.ufl.edu/bolker > GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 1670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] model.matrix evaluation challenges
Hi,
OK, yes, it does require some explanation...
What is the difference between your examples 2 and 3, where the first
has the formula given explicitly, and the second has the formula
assigned to the object? As you said, case 2 works while case 3 fails.
2. with(c(newdata,obj...@data),model.matrix(~f))
3. z <- ~f; with(c(newdata,obj...@data),model.matrix(z))
The difference is that the environment attached to the formula is
different. Its environment defaults to the evaluation frame in which
the formula was defined. This evaluation frame is different inside the
with() statement: in that case the evaluation frame includes the
elements of c(newdata, obj...@data).
If the 'data' argument is missing, model.matrix() will only look in
the environment of z, which in your example is external to the with()
frame.
So one approach is to redefine the environment of the formula z:
z <- ~f
with(c(newdata,obj...@data), {
environment(z) <- environment()
model.matrix(z)
})
Or, we can force model.matrix() to look in a given environment by
using its 'data' argument:
with(c(newdata,obj...@data),model.matrix(~f, data = environment()))
Hope that helps
-Felix
2009/8/12 Ben Bolker :
> that seems to work, thank you.
> would anyone care to explain *why* it works ... ? or where
> I could go to read more about why it works ... ?
>
> cheers
> Ben Bolker
>
>
> Felix Andrews wrote:
>> how about...
>>
>> nrow(with(cc, model.matrix(params, data=environment(
>>
>> cheers
>> -Felix
>>
>> 2009/8/10 Ben Bolker :
>>> I am having difficulty with evaluation/environment construction
>>> for a formula to be evaluated by model.matrix(). Basically, I
>>> want to construct a model matrix that first looks in "newdata"
>>> for the values of the model parameters, then in "obj...@data".
>>> Here's what I've tried:
>>>
>>> 1. model.matrix(~f,data=c(newdata,obj...@data)) -- fails because
>>> something (terms()?) within model.matrix() tries to coerce "data"
>>> to a data frame -- but newdata and obj...@data have different
>>> numbers of rows.
>>>
>>> 2. with(c(newdata,obj...@data),model.matrix(~f)) works --
>>> BUT not when ~f is assigned to another object (as it will be
>>> when it is being dug out of a previously fit model).
>>>
>>> 3. If "f" exists as a column within newdata and/or obj...@data,
>>> but the formula is assigned to another object (see below), then
>>> with(c(newdata,obj...@data),model.matrix(z)) fails -- because
>>> model.matrix() is explicitly evaluating the variables in the formula
>>> in the environment of z (i.e., ignoring the first argument of "with" ...)
>>>
>>>
>>> Any advice on how to solve this without making a bigger mess?
>>>
>>> sincerely
>>> Ben Bolker
>>>
>>>
>>> ## set up a data frame for prediction
>>>
>>> set.seed(1001)
>>> f = factor(rep(letters[1:4],each=20))
>>> x = runif(80)
>>> u = rnorm(4)
>>> y = rnorm(80,mean=2+x*(3+u[f]),sd=0.1)
>>> dat = data.frame(f,x,y)
>>>
>>> ## fit a model ... could easily do by lm() but want to
>>> ## demonstrate the problem
>>>
>>> library(bbmle)
>>> m1 = mle2(y~dnorm(a+b*x,sd=exp(logs)),parameters=list(b~f),data=dat,
>>> start=list(a=0,b=2,logs=-3))
>>>
>>> ## data frame for prediction
>>> pp0 = expand.grid(x=seq(0,1,length=11),
>>> f=levels(dat$f))
>>>
>>> ## combine frame and model data: have to keep the model data
>>> ## around, because it contain other information needed for
>>> ## prediction.
>>>
>>> cc = c(pp0,m...@data)
>>> try(mm <- model.matrix(~f,cc)) ## fails -- different number of rows
>>> ## (at some point R tries to coerce cc to a data frame)
>>> nrow(with(cc,model.matrix(~f))) ## works ... but ...
>>>
>>> ## here's what happens within predict.mle2()
>>> ## extract information about parameter models
>>> params <- eval(m...@call$parameters)
>>> params <- params[[1]]
>>> params[[2]] <- NULL
>>>
>>> nrow(with(cc,model.matrix(params)))
>>> rm(f)
>>> ## object "f" not found -- because model.matrix
>>> ## evaluates in the parent environment of params ...
>>> try(nrow(with(cc,model.matrix(params
>>>
>>>
>>>
>>> --
>>> Ben Bolker
>>> Associate profes
Re: [Rd] split.data.frame
I agree, I would definitely appreciate that.
A simpler implementation:
split.data.frame <- function(x, f, drop = FALSE, ...)
{
ff <- eval(substitute(f), x, parent.frame())
lapply(split(seq_len(nrow(x)), ff, drop = drop, ...),
function(ind) x[ind, , drop = FALSE])
}
df <- data.frame(x = 1:10, y = rep(1:2, each = 5))
split( df, df$y )
split( df, y )
split( df, x > 3 )
2009/12/15 Romain Francois :
> Hello,
>
> I very much enjoy "with" and "subset" semantics for data frames and was
> wondering if we could have something similar with split, basically by
> evaluating the second argument "with" the data frame :
>
> split.data.frame
> function(x, f, drop = FALSE, ...){
> call <- match.call( )
> fcall <- call( "with", data = call[["x"]], expr = call[["f"]] )
> ff <- eval( fcall, parent.frame(1) )
>
> lapply(split(seq_len(nrow(x)), ff, drop = drop, ...), function(ind)
> x[ind, , drop = FALSE])
> }
>
>
>> split( df, y )
> $`1`
> x y
> 1 1 1
> 2 2 1
> 3 3 1
> 4 4 1
> 5 5 1
>
> $`2`
> x y
> 6 6 2
> 7 7 2
> 8 8 2
> 9 9 2
> 10 10 2
>
>> split( df, x > 3 )
> $`FALSE`
> x y
> 1 1 1
> 2 2 1
> 3 3 1
>
> $`TRUE`
> x y
> 4 4 1
> 5 5 1
> 6 6 2
> 7 7 2
> 8 8 2
> 9 9 2
> 10 10 2
>
>
> Romain
>
> --
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
> |- http://tr.im/HlX9 : new package : bibtex
> |- http://tr.im/Gq7i : ohloh
> `- http://tr.im/FtUu : new package : highlight
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal for new axis.Date/axis.POSIXct
Hi R-devel.
I've noticed a couple of quirks in the current time/date axis
functions (axis.Date, axis.POSIXct, and the equivalents in lattice).
Looking at the code, it seems like a fairly ad-hoc approach, often
using pretty() on components of the time. This is not always ideal -
for example a one-hour interval gets cut into 10-minute chunks rather
than the more natural 15-minute chunks (since pretty() doesn't know
about the minutes in an hour, etc). Generally the number of tick marks
produced varies a lot, and there are a couple of strange cases: try
plot(0:1 ~ as.POSIXct(paste(2002:2003,"-02-01",sep="")))
So, I've written a function prettyDate() that attempts to act like
pretty(), but with dates and times. Like pretty, it takes arguments
'n' and 'min.n' which specify the desired and minimum number of ticks,
respectively.
http://pastie.org/751640
By the way, also listed there is an extension of trunc.POSIXt with
extra units "weeks", "months", "years", "decades", "centuries".
Following is a test of prettyDate() for axis labelling, drawn for a
sequence of different time intervals.
source("http://pastie.org/751640.txt";)
steps <-
list("10 secs",
"1 min", "5 mins", "10 mins", "15 mins", "30 mins",
"1 hour", "3 hours", "6 hours", "12 hours",
"1 DSTday", "1 week", "2 weeks",
"1 month", "3 months", "6 months",
"1 year", "2 years", "5 years", "10 years",
"20 years", "50 years", "100 years")
names(steps) <- paste("span =", unlist(steps))
from <- as.POSIXct("2002-02-02 02:02")
devAskNewPage(TRUE)
lapply(steps, function(s) {
times <- seq(from, by = s, length = 2)
plot(0:1 ~ times, yaxt = "n", ylab = "")
x <- mean(par("usr")[1:2])
text(x, 0.5, paste("span:", s), cex = 2)
text(x, 0.33, paste(format(times), collapse="\n"))
text(x, 0.05, "current axis.POSIXct")
text(x, 0.95, "proposed new prettyDate axis")
## draw new proposed axis function at top of plot
timelim <- par("usr")[1:2]
mostattributes(timelim) <- attributes(from)
axis(side = 3, at = prettyDate(timelim),
labels = prettyDate(timelim, do.format=TRUE))
})
devAskNewPage(FALSE)
Is it appropriate / desirable for this to be incorporated into R?
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A package for visualizing R syntax
Nice idea. But I think "visualR" or "seeR" are way too vague. How about "drawExpressions", or "showExpressions"? -Felix 2009/12/24 Sylvain Loiseau : > Dear all, > > I have written a small set of functions for drawing graphical representations > of R objects and evaluations of R expressions. > > It is mainly intended for pedagogical purposes. Here are some samples: > > http://panini.u-paris10.fr/~sloiseau/sampleGraphics.pdf > > The idea is to use some graphical conventions in order to make clear the > abstract syntax and to explain function, extraction, recycling, type > conversion, properties of data structures, etc. > > I would be very interested in your reactions and comments. I'm wondering if > it may become a R package. Does something like this already exist? May it be > useful? What improvement may be planned? Have you some idea for the name of > such a package (visualR, seeR... ?) > > Best regards, > Sylvain > -- > Sylvain Loiseau > sylvain.lois...@unicaen.fr > > Université de Caen Basse Normandie > Maison de la Recherche en Sciences Humaines > MRSH - SH018 > Esplanade de la Paix > Campus 1 > 14032 Caen Cedex > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] proposal for new axis.Date/axis.POSIXct
[reposting after holiday period]
-- Forwarded message --
From: Felix Andrews
Date: 21 December 2009 23:44
Subject: proposal for new axis.Date/axis.POSIXct
To: r-devel@r-project.org
Hi R-devel.
I've noticed a couple of quirks in the current time/date axis
functions (axis.Date, axis.POSIXct, and the equivalents in lattice).
Looking at the code, it seems like a fairly ad-hoc approach, often
using pretty() on components of the time. This is not always ideal -
for example a one-hour interval gets cut into 10-minute chunks rather
than the more natural 15-minute chunks (since pretty() doesn't know
about the minutes in an hour, etc). Generally the number of tick marks
produced varies a lot, and there are a couple of strange cases: try
plot(0:1 ~ as.POSIXct(paste(2002:2003,"-02-01",sep="")))
So, I've written a function prettyDate() that attempts to act like
pretty(), but with dates and times. Like pretty, it takes arguments
'n' and 'min.n' which specify the desired and minimum number of ticks,
respectively.
http://pastie.org/751640
By the way, also listed there is an extension of trunc.POSIXt with
extra units "weeks", "months", "years", "decades", "centuries".
Following is a test of prettyDate() for axis labelling, drawn for a
sequence of different time intervals.
source("http://pastie.org/751640.txt";)
steps <-
list("10 secs",
"1 min", "5 mins", "10 mins", "15 mins", "30 mins",
"1 hour", "3 hours", "6 hours", "12 hours",
"1 DSTday", "1 week", "2 weeks",
"1 month", "3 months", "6 months",
"1 year", "2 years", "5 years", "10 years",
"20 years", "50 years", "100 years")
names(steps) <- paste("span =", unlist(steps))
from <- as.POSIXct("2002-02-02 02:02")
devAskNewPage(TRUE)
lapply(steps, function(s) {
times <- seq(from, by = s, length = 2)
plot(0:1 ~ times, yaxt = "n", ylab = "")
x <- mean(par("usr")[1:2])
text(x, 0.5, paste("span:", s), cex = 2)
text(x, 0.33, paste(format(times), collapse="\n"))
text(x, 0.05, "current axis.POSIXct")
text(x, 0.95, "proposed new prettyDate axis, n = 5")
## draw new proposed axis function at top of plot
timelim <- par("usr")[1:2]
mostattributes(timelim) <- attributes(from)
axis(side = 3, at = prettyDate(timelim),
labels = prettyDate(timelim, do.format=TRUE))
})
devAskNewPage(FALSE)
Is it appropriate / desirable for this to be incorporated into R?
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error on Windows build: "unable to re-encode"
Dear developers,
while our package TripleR (hosted on R-Forge) builds well on Mac and Linux, the
Windows build shows following error
(http://r-forge.r-project.org/R/?group_id=418&log=build_win32&pkg=TripleR&flavor=patched):
Fri Feb 26 00:53:38 2010: Building binary for package TripleR (SVN revision NA)
using R version 2.10.1 Patched (2010-02-24 r51172) ...
* installing to library 'R:/R/lib/CRAN/2.10'
* installing *source* package 'TripleR' ...
Using auto-selected zip option '--use-zip-data'
** R
Error : unable to re-encode 'RR.r'
I found the piece of code producing the error in the function
.install_package_code_files in the file src/library/tools/R/admin.R:
## assume that if locale is 'C' we can used 8-bit encodings unchanged.
if(need_enc && !(Sys.getlocale("LC_CTYPE") %in% c("C", "POSIX"))) {
con <- file(outFile, "a")
on.exit(close(con)) # Windows does not like files left open
for(f in codeFiles) {
tmp <- iconv(readLines(f, warn = FALSE), from = enc, to = "")
if(any(is.na(tmp)))
stop(gettextf("unable to re-encode '%s'", basename(f)),
domain = NA, call. = FALSE)
However, I don't really know what that means.
I already tried to encode the source file both in UTF-8 and in latin-1, but
neither worked.
Did anyone encounter the same problem / any suggestion?
Thanks a lot!
Felix
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error on Windows build: "unable to re-encode"
Thanks for your help - that was the solution (easy enough to remove these two characters - they've been in only comments anyway). Fortunately, the DECRIPTION file accepts umlauts, as in my second name. The problem was only in the source file. Felix Am 26.02.2010 um 18:37 schrieb Duncan Murdoch: > On 26/02/2010 11:05 AM, Felix Schönbrodt wrote: >> Hi Duncan, >> >> I now declared the endcoding in the DESCRIPTION to UTF-8 (and all files are >> encoded in that way, too). As my last name is "Schönbrodt", I'd be happy to >> see it that way in the package ;-) >> However, it still doesn't build on Windows (but works on Mac and Linux). >> Unfortunately I cannot build the Windows packages myself (I work on a Mac), >> but the win-builder by Uwe Ligges still shows the same error ... >> >> > If declaring the encoding in DESCRIPTION doesn't solve the problem, I'd be >> > happy to take a look at the package. >> >> That's a great offer! I'd be very happy if you could take a look. >> You can find the source at http://r-forge.r-project.org/projects/tripler/, a >> tar.gz is attached as well. > > > I got the same error as you. It looks as though iconv has trouble with the > way some characters are encoded in your file. For example, on line 893, you > have a u-umlaut encoded as EF BF BD. According the the UTF-8 tables at > http://www.utf8-chartable.de/unicode-utf8-table.pl?start=65280, that encodes > a question mark in a diamond, "REPLACEMENT CHARACTER". There's no > corresponding character in the standard Windows latin1 encoding, so > conversion fails. Firefox can display the funny question mark, but it > doesn't display the u-umlaut as you intended, so I think this is an error in > your file. > > A way to find all such errors is as follows: read the file as utf-8, then > use the iconv() function in R to convert it to latin1. When I do that, I get > NA on lines 893 and 953, which are displayed to me as > > [1] "\t# im latenten Fall: die Error variance erst am Ende berechnen (d.h., > alle error componenten �ber alle Gruppen mitteln, die unter NUll auf Null > setzen, dann addieren)" > [2] "\t\t# TODO: �berpr�fen!" > We might be able to make the error message in the package installer more > informative (e.g. giving the line number that failed). I'll look into that. > > Duncan Murdoch > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in aggregate.ts
Hi,
I am getting unexpected behaviour from aggregate.ts(). The 'ndeltat'
argument is effectively being reduced by 1 in some cases, even when it
is an integer, with the result that the blocks to be aggregated are
not of the expected size, and also that the end() of the aggregated
series is much later than the end() of the original series.
rawts <- ts(rep(1:10, each = 5), start = 1)
## ndeltat = 5, but splits into blocks of 4 rather than 5:
agts <- aggregate(rawts, ndeltat = 5,
FUN = function(x) {str(x);mean(x)})
int [1:4] 1 1 1 1
int [1:4] 1 2 2 2
int [1:4] 2 2 3 3
int [1:4] 3 3 3 4
int [1:4] 4 4 4 4
int [1:4] 5 5 5 5
int [1:4] 5 6 6 6
int [1:4] 6 6 7 7
int [1:4] 7 7 7 8
int [1:4] 8 8 8 8
int [1:4] 9 9 9 9
int [1:4] 9 10 10 10
## Adding a small amount onto ndeltat bumps it up to blocks of 5:
agts2 <- aggregate(rawts, ndeltat = 5 + getOption("ts.eps") / 2,
FUN = function(x) {str(x);mean(x)})
int [1:5] 1 1 1 1 1
int [1:5] 2 2 2 2 2
int [1:5] 3 3 3 3 3
int [1:5] 4 4 4 4 4
int [1:5] 5 5 5 5 5
int [1:5] 6 6 6 6 6
int [1:5] 7 7 7 7 7
int [1:5] 8 8 8 8 8
int [1:5] 9 9 9 9 9
int [1:5] 10 10 10 10 10
## Compare start / end / deltat / length for the two series.
sapply(list(`ndeltat=5` = agts, `ndeltat=5+` = agts2),
function(x) c(start = start(x)[1], end = end(x)[1],
deltat = deltat(x), length = length(x)))
#ndeltat=5 ndeltat=5+
# start 1 1.00
# end 56 46.45 ## `rawts` ends at 50
# deltat 5 5.05
# length12 10.00
sessionInfo()
R version 2.11.0 RC (2010-04-18 r51771)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in aggregate.ts
Sorry, I didn't notice Patrick Aboyoun's email reporting the same
issue just some minutes ago.
On 20 April 2010 10:41, Felix Andrews wrote:
> Hi,
>
> I am getting unexpected behaviour from aggregate.ts(). The 'ndeltat'
> argument is effectively being reduced by 1 in some cases, even when it
> is an integer, with the result that the blocks to be aggregated are
> not of the expected size, and also that the end() of the aggregated
> series is much later than the end() of the original series.
>
> rawts <- ts(rep(1:10, each = 5), start = 1)
>
> ## ndeltat = 5, but splits into blocks of 4 rather than 5:
>
> agts <- aggregate(rawts, ndeltat = 5,
> FUN = function(x) {str(x);mean(x)})
> int [1:4] 1 1 1 1
> int [1:4] 1 2 2 2
> int [1:4] 2 2 3 3
> int [1:4] 3 3 3 4
> int [1:4] 4 4 4 4
> int [1:4] 5 5 5 5
> int [1:4] 5 6 6 6
> int [1:4] 6 6 7 7
> int [1:4] 7 7 7 8
> int [1:4] 8 8 8 8
> int [1:4] 9 9 9 9
> int [1:4] 9 10 10 10
>
> ## Adding a small amount onto ndeltat bumps it up to blocks of 5:
>
> agts2 <- aggregate(rawts, ndeltat = 5 + getOption("ts.eps") / 2,
> FUN = function(x) {str(x);mean(x)})
> int [1:5] 1 1 1 1 1
> int [1:5] 2 2 2 2 2
> int [1:5] 3 3 3 3 3
> int [1:5] 4 4 4 4 4
> int [1:5] 5 5 5 5 5
> int [1:5] 6 6 6 6 6
> int [1:5] 7 7 7 7 7
> int [1:5] 8 8 8 8 8
> int [1:5] 9 9 9 9 9
> int [1:5] 10 10 10 10 10
>
> ## Compare start / end / deltat / length for the two series.
>
> sapply(list(`ndeltat=5` = agts, `ndeltat=5+` = agts2),
> function(x) c(start = start(x)[1], end = end(x)[1],
> deltat = deltat(x), length = length(x)))
>
> # ndeltat=5 ndeltat=5+
> # start 1 1.00
> # end 56 46.45 ## `rawts` ends at 50
> # deltat 5 5.05
> # length 12 10.00
>
>
> sessionInfo()
> R version 2.11.0 RC (2010-04-18 r51771)
> i386-pc-mingw32
>
> locale:
> [1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
> [3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
> [5] LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
>
>
> --
> Felix Andrews / 安福立
> Postdoctoral Fellow
> Integrated Catchment Assessment and Management (iCAM) Centre
> Fenner School of Environment and Society [Bldg 48a]
> The Australian National University
> Canberra ACT 0200 Australia
> M: +61 410 400 963
> T: + 61 2 6125 4670
> E: felix.andr...@anu.edu.au
> CRICOS Provider No. 00120C
> --
> http://www.neurofractal.org/felix/
>
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in cut.POSIXt(..., breaks = ) and cut.Date
x <- seq(as.POSIXct("2000-01-01"), by = "days", length = 20)
cut(x, breaks = 3)
# Error in `levels<-.factor`(`*tmp*`, value = character(0)) :
# number of levels differs
cut(as.Date(x), breaks = 3)
# Error in `levels<-.factor`(`*tmp*`, value = character(0)) :
# number of levels differs
Index: base/R/datetime.R
===
--- base/R/datetime.R (revision 51857)
+++ base/R/datetime.R (working copy)
@@ -775,7 +775,11 @@
}
} else stop("invalid specification of 'breaks'")
res <- cut(unclass(x), unclass(breaks), labels = labels, right =
right, ...)
-if(is.null(labels)) levels(res) <- as.character(breaks[-length(breaks)])
+if(is.null(labels)) {
+if (is.numeric(breaks))
+levels(res) <- as.character(x[!duplicated(res)])
+else levels(res) <- as.character(breaks[-length(breaks)])
+}
res
}
Index: base/R/dates.R
===
--- base/R/dates.R (revision 51857)
+++ base/R/dates.R (working copy)
@@ -362,7 +362,11 @@
} else stop("invalid specification of 'breaks'")
res <- cut(unclass(x), unclass(breaks), labels = labels,
right = right, ...)
-if(is.null(labels)) levels(res) <- as.character(breaks[-length(breaks)])
+if(is.null(labels)) {
+if (is.numeric(breaks))
+levels(res) <- as.character(x[!duplicated(res)])
+ else levels(res) <- as.character(breaks[-length(breaks)])
+}
res
}
Regards
-Felix
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pretty.Date(): new "halfmonth" time step
Hi R-devel / R-core
In the new pretty() methods for Date and POSIXct
https://svn.r-project.org/R/trunk/src/library/grDevices/R/prettyDate.R
there is currently a "pretty" time step listed as "15 DSTdays"... but
this actually doesn't line up well with months.
Much better to implement directly what this is trying to do: i.e. to
have a "halfmonth" time step. This is just the union of two "monthly"
sequences, one on the 1st of each month and another on the 15th of
each month.
With this in place we have:
prettyDate(as.Date(c("2002-02-02", "2002-05-01")))
# [1] "2002-02-15" "2002-03-01" "2002-03-15" "2002-04-01" "2002-04-15"
"2002-05-01"
The proposed patch is attached.
Regards
-Felix
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pretty.Date(): new "halfmonth" time step
On 20 May 2010 11:56, Daniel Murphy wrote:
>>Much better to implement directly what this is trying to do: i.e. to
>>have a "halfmonth" time step. This is just the union of two "monthly"
>>sequences, one on the 1st of each month and another on the 15th of
>>each month.
>
> For some applications that might be true. But not for others. For a month
> with 31 days, there are 14 days before the 15th of the month and 16 days
> after the 15th, so, for example, March 16th (specifically noon) rather than
> March 15th would be the halfway point if you define "halfway" in terms of
> the distances to the beginning and end of the month. For a month with 30
> days -- like April -- the halfway point would be the instant between the
> 15th and the 16th of the month. Do you label that instant April 15 or April
> 16? (I prefer "15".) Don't get me started on February.
Dan, you are correct: the midpoint of a 30 day month is the 16th at
00:00. That instant is called the 16th according to print.POSIXt.
junstart <- as.POSIXct("2000-06-01 00:00", tz="GMT")
julstart <- as.POSIXct("2000-07-01 00:00", tz="GMT")
junstart + ((julstart - junstart) / 2)
#[1] "2000-06-16 GMT"
How embarassing...
So I think it would be better to use 16 rather than 15 for the
"halfmonth" time step.
Yes, months have variable lengths, but I think it is best to use a
consistent date (the 16th) than to calculate exact midpoints, just as
a normal monthly series has a consistent date (the 1st) and has
variable lengths.
Regards
-Felix
>
> - Dan Murphy
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pretty.Date(): new "halfmonth" time step
I see, an interesting perspective.
The current purpose is just to look pretty, or to follow "the
principle of least surprise", which is difficult to the extent that it
is subjective and sometimes context dependent...
Cheers
-Felix
On 20 May 2010 17:38, Daniel Murphy wrote:
> Felix,
> I see your point about the "halfway" point acting like the first day of the
> month in its relativity to the ending date of the month: they're both
> variable.
> I'm an actuary. Like accountants, actuaries tend to measure "financial" time
> in months because of how the books close. But in our mathematical models
> time takes on a continuous nature. So our problem is how to build a computer
> representation of time that reflects both its continuous nature as well as
> the varying-length, "discrete" nature of financial months. I've found that a
> fixed value for a halfway point complicates actuarial calculations. It could
> serve other purposes just fine, however.
> Best regards,
> Dan
>
> On Wed, May 19, 2010 at 7:48 PM, Felix Andrews wrote:
>>
>> On 20 May 2010 11:56, Daniel Murphy wrote:
>> >>Much better to implement directly what this is trying to do: i.e. to
>> >>have a "halfmonth" time step. This is just the union of two "monthly"
>> >>sequences, one on the 1st of each month and another on the 15th of
>> >>each month.
>> >
>> > For some applications that might be true. But not for others. For a
>> > month
>> > with 31 days, there are 14 days before the 15th of the month and 16 days
>> > after the 15th, so, for example, March 16th (specifically noon) rather
>> > than
>> > March 15th would be the halfway point if you define "halfway" in terms
>> > of
>> > the distances to the beginning and end of the month. For a month with 30
>> > days -- like April -- the halfway point would be the instant between the
>> > 15th and the 16th of the month. Do you label that instant April 15 or
>> > April
>> > 16? (I prefer "15".) Don't get me started on February.
>>
>> Dan, you are correct: the midpoint of a 30 day month is the 16th at
>> 00:00. That instant is called the 16th according to print.POSIXt.
>>
>> junstart <- as.POSIXct("2000-06-01 00:00", tz="GMT")
>> julstart <- as.POSIXct("2000-07-01 00:00", tz="GMT")
>> junstart + ((julstart - junstart) / 2)
>> #[1] "2000-06-16 GMT"
>>
>> How embarassing...
>> So I think it would be better to use 16 rather than 15 for the
>> "halfmonth" time step.
>>
>> Yes, months have variable lengths, but I think it is best to use a
>> consistent date (the 16th) than to calculate exact midpoints, just as
>> a normal monthly series has a consistent date (the 1st) and has
>> variable lengths.
>>
>> Regards
>> -Felix
>>
>>
>> >
>> > - Dan Murphy
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>>
>> --
>> Felix Andrews / 安福立
>> Postdoctoral Fellow
>> Integrated Catchment Assessment and Management (iCAM) Centre
>> Fenner School of Environment and Society [Bldg 48a]
>> The Australian National University
>> Canberra ACT 0200 Australia
>> M: +61 410 400 963
>> T: + 61 2 6125 4670
>> E: felix.andr...@anu.edu.au
>> CRICOS Provider No. 00120C
>> --
>> http://www.neurofractal.org/felix/
>
>
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pretty.Date(): changes to axis() methods?
Hi all.
pretty() is now generic in R-2.12 and there are new methods for Date
and POSIXt classes. These methods could potentially be used inside
axis.Date and axis.POSIXt (and Axis methods), although that has not
been decided yet.
The main advantage of the new method is that it is flexible, in the
sense that users can specify the desired number of ticks on an axis.
(e.g. one could easily draw, say, labelled ticks with n = 5, and then
sub-ticks with n = 15). Of course one can do this manually but
it is not so convenient.
[[ On this issue: I don't use base graphics much, but given how
awkward it is to specify par("xaxp") / par("yaxp"), perhaps a new
axis.Date() should gain arguments 'n' and 'min.n' to pass on to
pretty(). Example given below. ]]
The current version of pretty.Date / pretty.POSIXt gives different
results in some cases to axis.Date / axis.POSIXt: the format strings
for time steps of 1 day, 12 hours and 6 hours are different; and some
different time steps are allowed, such as 10 minutes, 3 hours, 3
months... the full list of possible time steps and their current
default format strings is listed at:
http://svn.r-project.org/R/trunk/src/library/grDevices/R/prettyDate.R
The current axis.Date / axis.POSIXt code, including format strings, is
http://svn.r-project.org/R/trunk/src/library/graphics/R/datetime.R
These settings reflect my personal choices, but are somewhat
arbitrary. I would encourage R-core to make this function their own,
by choosing default format strings and time steps with which they are
comfortable. It could be made more similar to the current axis
methods. E.g. it wouldn't much bother me to remove the "15 mins" time
steps altogether, and a "20 mins" time step could be added.
Here is an example of changing the number of requested ticks on an
axis: (this example does not depend on R 2.12)
source("http://svn.r-project.org/R/trunk/src/library/grDevices/R/prettyDate.R";)
times <- as.Date(c("2000-04-02", "2000-06-02"))
devAskNewPage(TRUE)
lapply(c(2,4,6,8,10,20,60), function(n) {
plot(0:1 ~ times, type = "n", yaxt = "n", ylab = "")
x <- par("usr")[1:2]
text(x[1], 0.5, format(times[1]), pos = 4)
text(x[2], 0.5, format(times[2]), pos = 2)
text(mean(x), 0.05, "current axis.Date()")
text(mean(x), 0.95, "proposed new pretty() axis, with")
text(mean(x), 0.85, paste("n =", n), cex = 1.5)
## draw new proposed axis function at top of plot
timelim <- par("usr")[1:2]
mostattributes(timelim) <- attributes(times)
at <- prettyDate(timelim, n = n)
axis(side = 3, at = at, labels = attr(at, "labels"))
})
Here is a posible modification to axis.Date. As it calls pretty(), it
will only work in R 2.12.
axis.Date <- function(side, x = NA, at, format, labels = TRUE, n = NULL, ...)
{
mat <- missing(at) || is.null(at)
if(!mat) x <- as.Date(at) else x <- as.Date(x)
range <- par("usr")[if(side %%2) 1L:2L else 3:4L]
range[1L] <- ceiling(range[1L])
range[2L] <- floor(range[2L])
class(range) <- "Date"
## not sure why we need this (from axis.Date):
z <- c(range, x[is.finite(x)])
class(z) <- "Date"
if (!mat) {
## tick mark locations given
z <- x[is.finite(x)]
if (missing(format)) format <- ""
} else {
## calculate about 'n' pretty intervals
if (is.null(n)) {
is.x <- side %% 2 == 1
axp <- par(if (is.x) "xaxp" else "yaxp")
n <- abs(axp[3L])
}
z <- pretty(z, n = n)
if (missing(format) && identical(labels, TRUE))
labels <- attr(z, "labels")
}
keep <- z >= range[1L] & z <= range[2L]
z <- z[keep]
z <- sort(unique(z)); class(z) <- "Date"
if (!is.logical(labels)) labels <- labels[keep]
else if (identical(labels, TRUE))
labels <- format.Date(z, format = format)
else if (identical(labels, FALSE))
labels <- rep("", length(z)) # suppress labelling of ticks
axis(side, at = z, labels = labels, ...)
}
Whether to modify axis() methods is up to R-core of course, but I
thought it was worth discussing.
By the way, this new functionality is already included in lattice
0.18-5, which was released with, and depends on, R 2.11.0. (There is
one known issue: the Date method in lattice 0.18-5 can miss a tick at
one end of the axis if your local time zone is not "GMT". Also that
version does not include the new "halfmonth" time step.)
-Felix
--
Felix Andrews / 安福立
Postdoctoral Fellow
Integrated Catchment Assessment and Management (iCAM) Centre
Fenner School of Environment and Society [Bldg 48a]
The Australian National University
Canberra ACT 0200 Australia
M: +61 410 400 963
T: + 61 2 6125 4670
E: felix.andr...@anu.edu.au
CRICOS Provider No. 00120C
--
http://www.neurofractal.org/felix/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] SVN vs DVCS
Hi, Just wondering whether anyone had thought about moving the R sources to a "distributed" version control system such as Bazaar, Git or Mercurial. These new generation systems make it easier to work on feature branches, allow working offline, are very fast, etc. Some projects that have moved to Git are Linux Kernel Perl Ruby on Rails ... http://en.wikipedia.org/wiki/Git_(software) Some projects that have moved to Bazaar (bzr) are Ubuntu MySQL Inkscape ... http://en.wikipedia.org/wiki/Bazaar_(software) Some projects that have moved to Mercurial (hg) are Mozilla Octave Python ... http://en.wikipedia.org/wiki/Mercurial_(software) Joel Spolky's take on it: http://www.joelonsoftware.com/items/2010/03/17.html Regards -Felix -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
On second thoughts it is really none of my business how the R sources are managed. But I would encourage package developers and/or r-forge maintainers to consider these systems. Regards -Felix On 26 May 2010 10:29, Felix Andrews wrote: > Hi, > > Just wondering whether anyone had thought about moving the R sources > to a "distributed" version control system such as Bazaar, Git or > Mercurial. These new generation systems make it easier to work on > feature branches, allow working offline, are very fast, etc. > > Some projects that have moved to Git are > Linux Kernel > Perl > Ruby on Rails > ... > http://en.wikipedia.org/wiki/Git_(software) > > Some projects that have moved to Bazaar (bzr) are > Ubuntu > MySQL > Inkscape > ... > http://en.wikipedia.org/wiki/Bazaar_(software) > > Some projects that have moved to Mercurial (hg) are > Mozilla > Octave > Python > ... > http://en.wikipedia.org/wiki/Mercurial_(software) > > Joel Spolky's take on it: > http://www.joelonsoftware.com/items/2010/03/17.html > > Regards > -Felix > > -- > Felix Andrews / 安福立 > Postdoctoral Fellow > Integrated Catchment Assessment and Management (iCAM) Centre > Fenner School of Environment and Society [Bldg 48a] > The Australian National University > Canberra ACT 0200 Australia > M: +61 410 400 963 > T: + 61 2 6125 4670 > E: felix.andr...@anu.edu.au > CRICOS Provider No. 00120C > -- > http://www.neurofractal.org/felix/ > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
I'm not necessarily advocating a migration; probably an administrative nightmare, and everyone involved would be forced to learn new stuff... I was just enthusing because I recently started using a DVCS for the first time. On 26 May 2010 21:16, Gabor Grothendieck wrote: > Note that one can also use any of the dvcs systems without actually > moving from svn by using the dvcs (or associated extension/addon) as > an svn client or by using it on an svn checkout. Yes, that's a very good point (although in my experience it takes a very long time to do the initial download of the SVN repository). I'm not an expert on these systems, but I imagine the main downside (other than speed) of having SVN upstream is that you have to keep the history linear, and so e.g can't collaborate on feature branches this way. But yeah, worth a go. > > On Wed, May 26, 2010 at 5:44 AM, Martin Maechler > wrote: >>>>>>> Felix Andrews >>>>>>> on Wed, 26 May 2010 11:20:12 +1000 writes: >> >> > On second thoughts it is really none of my business how the R sources >> > are managed. >> > But I would encourage package developers and/or r-forge maintainers to >> > consider these systems. >> >> Thank you, Felix, for the compilation of these alternatives. >> >> One very relevant piece of information that you've not added, >> is, how easily one could *move* from svn to such a system >> (including the full history of every file with revision numbers, >> log messages, etc), Indeed... here is the basic process for migrating to Git http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ This will keep the branches, tags, full history, with SVN revision numbers added to the log messages (if you leave off the --no-metadata argument). However, the actual commit ids you would use in git log / git diff / etc will not be the same as the old SVN ids. In fact git uses hash strings rather than numbers, and bazaar uses sequential numbering in each branch (rather than sequential numbers globally as SVN does). Not sure about Mercurial. >> and .. for R-forge, e.g., which of these provide nice and >> flexible tools (as svn does) for an automatic web interface to >> inspect file histories, differences, etc. All have web interfaces. In fact FusionForge, which is the new name for G-Forge, apparently supports Git, Bzr and Hg http://fusionforge.org/ https://alioth.debian.org/scm/?group_id=30261 http://wiki.debian.org/Alioth/Hg Other examples of web interfaces can be seen on the hosting services GitHub.com e.g. http://github.com/hadley/ggplot2 Canonical's launchpad.net (bzr) e.g. https://launchpad.net/igraph >> >> Regards, >> Martin ( maintainer of svn.r-project.org ) >> >> > Regards >> > -Felix >> >> > On 26 May 2010 10:29, Felix Andrews wrote: >> >> Hi, >> >> >> >> Just wondering whether anyone had thought about moving the R sources >> >> to a "distributed" version control system such as Bazaar, Git or >> >> Mercurial. These new generation systems make it easier to work on >> >> feature branches, allow working offline, are very fast, etc. >> >> >> >> Some projects that have moved to Git are >> >> Linux Kernel >> >> Perl >> >> Ruby on Rails >> >> ... >> >> http://en.wikipedia.org/wiki/Git_(software) >> >> >> >> Some projects that have moved to Bazaar (bzr) are >> >> Ubuntu >> >> MySQL >> >> Inkscape >> >> ... >> >> http://en.wikipedia.org/wiki/Bazaar_(software) >> >> >> >> Some projects that have moved to Mercurial (hg) are >> >> Mozilla >> >> Octave >> >> Python >> >> ... >> >> http://en.wikipedia.org/wiki/Mercurial_(software) >> >> >> >> Joel Spolky's take on it: >> >> http://www.joelonsoftware.com/items/2010/03/17.html >> >> >> >> Regards >> >> -Felix > -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] slow graphics on MAC OS X R-2.4.1 (PR#9530)
We use R a lot for graphics and noticed very slow graphics in Quartz mode where X11 is much faster. Our hardware: intel mac pro and intel macbook pro, both are affected. os versions: OS X Tiger 10.4.8 R version: R version 2.4.1 (2006-12-18) We tried the following simple thing. - Open the R program from the dock (not from the command line) - run the following two lines: d = matrix(runif(300*2000),300,2000) image(d) image(d) #again a second time and see how long it takes to appear on screen the first time, and again the second time. Then close R and open an X11 terminal and start R from the command line. try the same commands d = matrix(runif(300*2000),300,2000) image(d) image(d) #again a second time We found huge differences in speed, perhaps we are doing something wrong? As a result we exclusively use R in X11 mode which works fine for us. Felix Naef [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] plot.dendrogram xlim/ylim
list(...),
I would like to zoom in to the leaves of large trees in a dendrogram
plot. The playwith package allows zooming by passing xlim and ylim
arguments to the plot call (Hmisc does this too I think). But
currently stats:::plot.dendrogram does not accept xlim or ylim. So I
would like to enable that. In place of the existing code chunk:
xlim <- c(x1 - 1/2, x2 + 1/2)
ylim <- c(0, yTop)
if (horiz) {
xl <- xlim
xlim <- rev(ylim)
ylim <- xl
tmp <- xaxt
xaxt <- yaxt
yaxt <- tmp
}
plot(0, xlim = xlim, ylim = ylim, ..
I propose something like:
function(..., xlim, ylim)
xlim0 <- c(x1 - 1/2, x2 + 1/2)
ylim0 <- c(0, yTop)
if (horiz) {
xl <- xlim0
xlim0 <- rev(ylim0)
ylim <- xl
tmp <- xaxt
xaxt <- yaxt
yaxt <- tmp
}
if (missing(xlim)) xlim <- xlim0
if (missing(ylim)) ylim <- ylim0
plot(0, xlim = xlim, ylim = ylim, ..
Regards,
Felix
--
Felix Andrews / 安福立
PhD candidate
Integrated Catchment Assessment and Management Centre
The Fenner School of Environment and Society
The Australian National University (Building 48A), ACT 0200
Beijing Bag, Locked Bag 40, Kingston ACT 2604
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grobX for points?
Hi R-devel,
It seems that grobX and grobY (from the grid package) do not refer to
the bounding box of a grid.points object.
library(grid)
library(lattice)
xyplot(1:10 ~ 1:10)
downViewport("plot1.panel.1.1.vp")
grob <- grid.get("GRID.points", grep=TRUE)
convertX(grobWidth(grob), "cm")
# 10.3430190058480cm
# (correct, but:)
convertX(grobX(grob, "west"), "cm")
# 5.8955208333cm
convertX(grobX(grob, "east"), "cm")
# 5.8955208334cm
So grobX is returning the midpoint, rather than the bounding box. This
is surprising, given that ?grobX says "If the grob describes multiple
shapes, in most cases, the boundary value will correspond to the edge
of a bounding box around all of the shapes."
> sessionInfo()
R version 2.7.1 (2008-06-23)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
other attached packages:
[1] playwith_0.9-10 cairoDevice_2.8 gWidgetsRGtk2_0.0-36
RGtk2_2.12.5-3 gWidgets_0.0-28
[6] lattice_0.17-10
loaded via a namespace (and not attached):
[1] gridBase_0.4-3 tools_2.7.1
--
Felix Andrews / 安福立
PhD candidate
Integrated Catchment Assessment and Management Centre
The Fenner School of Environment and Society
The Australian National University (Building 48A), ACT 0200
Beijing Bag, Locked Bag 40, Kingston ACT 2604
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grobX for points?
On Mon, Jul 28, 2008 at 7:41 AM, Paul Murrell <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> Felix Andrews wrote:
>> Hi R-devel,
>>
>> It seems that grobX and grobY (from the grid package) do not refer to
>> the bounding box of a grid.points object.
>>
>> library(grid)
>> library(lattice)
>> xyplot(1:10 ~ 1:10)
>> downViewport("plot1.panel.1.1.vp")
>> grob <- grid.get("GRID.points", grep=TRUE)
>> convertX(grobWidth(grob), "cm")
>> # 10.3430190058480cm
>> # (correct, but:)
>> convertX(grobX(grob, "west"), "cm")
>> # 5.8955208333cm
>> convertX(grobX(grob, "east"), "cm")
>> # 5.8955208334cm
>>
>> So grobX is returning the midpoint, rather than the bounding box. This
>> is surprising, given that ?grobX says "If the grob describes multiple
>> shapes, in most cases, the boundary value will correspond to the edge
>> of a bounding box around all of the shapes."
>
>
> The grobX() and grobY() calculations for "points" grobs is "imperfect"
> because it treats the grob as a set of point locations and does NOT take
> into account the size and shape of the actual data symbols. This means
> that a points grob is not treated as multiple shapes, but in fact as a
> single set of points. Hence, the calculations of the boundary for the
> shape generate a convex hull around the point locations. In this case,
> the points all lie along a straight line, so the convex hull is a long
> thin "cigar" at a 45 degree angle. The calculation of points on this
> boundary draws a line from the centre of the convex hull to the edge.
> In this case, the line will intersect the convex hull boundary at the
> centre of the set of points for all angles (apart from possibly 45
> degrees).
>
> If you want to work with the bounding box for the points, perhaps you
> could draw an invisible rectangle based on the range of the data and
> work off that, or just use convertX() on the range of the data (?)
I am doing the latter, which is easy enough. Can I suggest that
grobX.Rd be updated to mention that it returns the convex hull for
points, lines and segments (?) objects? It currently reads
"If the grob describes multiple shapes, in most cases, the boundary
value will correspond to the edge of a bounding box around all of the
shapes. The exception to this is a polygon grob describing multiple
polygons; in that case, the edge corresponds to a convex hull around
all points of all polygons described by the grob."
Regards,
Felix
>
> Paul
>
>
>>> sessionInfo()
>> R version 2.7.1 (2008-06-23)
>> i386-pc-mingw32
>>
>> locale:
>> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>>
>> attached base packages:
>> [1] grid stats graphics grDevices utils datasets
>> methods base
>>
>> other attached packages:
>> [1] playwith_0.9-10 cairoDevice_2.8 gWidgetsRGtk2_0.0-36
>> RGtk2_2.12.5-3 gWidgets_0.0-28
>> [6] lattice_0.17-10
>>
>> loaded via a namespace (and not attached):
>> [1] gridBase_0.4-3 tools_2.7.1
>>
>>
>
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> [EMAIL PROTECTED]
> http://www.stat.auckland.ac.nz/~paul/
>
--
Felix Andrews / 安福立
PhD candidate
Integrated Catchment Assessment and Management Centre
The Fenner School of Environment and Society
The Australian National University (Building 48A), ACT 0200
Beijing Bag, Locked Bag 40, Kingston ACT 2604
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grid.ls() after grid.remove() fails
Dr Murrell and others,
It seems grid.ls() fails after any use of grid.remove(). It gives an
infinite recursion error even in the simplest cases, and no matter
what arguments are passed to grid.ls.
> library(grid)
> grid.newpage()
> grid.lines(name="foo")
> grid.ls()
foo
> grid.remove("foo")
> grid.ls()
Error: evaluation nested too deeply: infinite recursion / options(expressions=)?
> grid.ls(recursive=FALSE)
Error: evaluation nested too deeply: infinite recursion / options(expressions=)?
> str(grid.ls(print=FALSE))
Error: evaluation nested too deeply: infinite recursion / options(expressions=)?
> traceback()
...etc...
...etc...
...etc...
13: gridList.default(X[[2L]], ...)
12: FUN(X[[2L]], ...)
11: lapply(display.list[1:dl.index], gridList, grobs = grobs,
viewports = viewports,
fullNames = fullNames, recursive = recursive)
10: gridList.default(X[[2L]], ...)
9: FUN(X[[2L]], ...)
8: lapply(display.list[1:dl.index], gridList, grobs = grobs, viewports
= viewports,
fullNames = fullNames, recursive = recursive)
7: gridList.default(X[[2L]], ...)
6: FUN(X[[2L]], ...)
5: lapply(display.list[1:dl.index], gridList, grobs = grobs, viewports
= viewports,
fullNames = fullNames, recursive = recursive)
4: gridList.default(x, grobs = grobs, viewports = viewports, fullNames
= fullNames,
recursive = recursive)
3: gridList(x, grobs = grobs, viewports = viewports, fullNames = fullNames,
recursive = recursive)
2: grid.ls(print = FALSE)
1: str(grid.ls(print = FALSE))
> str(current.vpTree())
List of 17
$ x :Class 'unit' atomic [1:1] 0.5
.. ..- attr(*, "unit")= chr "npc"
.. ..- attr(*, "valid.unit")= int 0
$ y :Class 'unit' atomic [1:1] 0.5
.. ..- attr(*, "unit")= chr "npc"
.. ..- attr(*, "valid.unit")= int 0
$ width :Class 'unit' atomic [1:1] 1
.. ..- attr(*, "unit")= chr "npc"
.. ..- attr(*, "valid.unit")= int 0
$ height:Class 'unit' atomic [1:1] 1
.. ..- attr(*, "unit")= chr "npc"
.. ..- attr(*, "valid.unit")= int 0
$ justification : chr "centre"
$ gp: list()
..- attr(*, "class")= chr "gpar"
$ clip : logi TRUE
$ xscale: num [1:2] 0 558
$ yscale: num [1:2] 557 0
$ angle : num 0
$ layout: NULL
$ layout.pos.row: NULL
$ layout.pos.col: NULL
$ valid.just: num [1:2] 0.5 0.5
$ valid.pos.row : NULL
$ valid.pos.col : NULL
$ name : chr "ROOT"
- attr(*, "class")= chr "viewport"
> sessionInfo()
R version 2.8.0 Under development (unstable) (2008-07-26 r46127)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
--
Felix Andrews / 安福立
PhD candidate
Integrated Catchment Assessment and Management Centre
The Fenner School of Environment and Society
The Australian National University (Building 48A), ACT 0200
Beijing Bag, Locked Bag 40, Kingston ACT 2604
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] equivalent to "require" for imports? (cairoDevice)
Hi R-devel I use the packages RGtk2 and cairoDevice. The cairoDevice package has a few stand-alone functions, plus "asCairoDevice" which depends on RGtk2 and calls require(RGtk2). So cairoDevice lists RGtk2 under "Suggests" in the DESCRIPTION file. It can not Import RGtk2 because that would force all users to install RGtk2. The upshot of this is, if you *import* the RGtk2 namespace into another package and then call asCairoDevice(), RGtk2 is attached to the user's search path. That is significant because RGtk2 exports a large number of objects: -- 7476 to be exact -- which can clog up things like help.search and autocompletion. What is the recommended solution? Could asCairoDevice call loadNamespace rather than require? -- Felix Andrews / 安福立 PhD candidate Integrated Catchment Assessment and Management Centre The Fenner School of Environment and Society The Australian National University (Building 48A), ACT 0200 Beijing Bag, Locked Bag 40, Kingston ACT 2604 http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] conditionally import a namespace?
Dear R-devel, I have a problem defining the dependencies for a package. My package (latticist, not yet released) "Suggests" RGtk2, but specifically does not require it. If RGtk2 is available, the user can call a function that builds a GUI with RGtk2. However, I do not want to attach the RGtk2 namespace, because it is irrelevant to the user and exports about 7500 symbols. Last time I asked a similar question to this, Professor Ripley noted that the usual method to get around this situation is the use an explicit package prefix to function calls (the `::` operator). But this is not so easy with non-standard functions. Take this chunk of code: widg <- gtkComboBoxEntryNewText() widg$show() widg["width-request"] <- 100 The first call is easy to prefix, as RGtk2::gtkComboBoxEntryNewText() but the others, `$.RGtkObject` and `[<-.RGtkObject` are not. While I *could* rewrite all the code to use explicit functions, I think, the resulting code would be much less clear. Essentially what I want to do is conditionally import the RGtk2 namespace. Any suggestions? Thanks Felix -- Felix Andrews / 安福立 http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] conditionally import a namespace?
2008/10/31 Duncan Murdoch <[EMAIL PROTECTED]>:
> On 10/30/2008 10:44 AM, Duncan Murdoch wrote:
>>
>> On 10/30/2008 10:15 AM, Martin Maechler wrote:
>>>>>>>>
>>>>>>>> "FA" == Felix Andrews <[EMAIL PROTECTED]>
>>>>>>>>on Thu, 30 Oct 2008 17:40:17 +1100 writes:
>>>
>>>FA> Dear R-devel,
>>>FA> I have a problem defining the dependencies for a package.
>>>
>>>FA> My package (latticist, not yet released) "Suggests" RGtk2, but
>>>FA> specifically does not require it. If RGtk2 is available, the user
>>> can
>>>FA> call a function that builds a GUI with RGtk2. However, I do not
>>> want
>>>FA> to attach the RGtk2 namespace, because it is irrelevant to the
>>> user
>>>FA> and exports about 7500 symbols.
>>>
>>>FA> Last time I asked a similar question to this, Professor Ripley
>>> noted
>>>FA> that the usual method to get around this situation is the use an
>>>FA> explicit package prefix to function calls (the `::` operator). But
>>>FA> this is not so easy with non-standard functions. Take this chunk
>>> of
>>>FA> code:
>>>
>>>FA> widg <- gtkComboBoxEntryNewText()
>>>FA> widg$show()
>>>FA> widg["width-request"] <- 100
>>>
>>>FA> The first call is easy to prefix, as
>>> RGtk2::gtkComboBoxEntryNewText()
>>>FA> but the others, `$.RGtkObject` and `[<-.RGtkObject` are not.
>>>
>>> indeed.
>>>
>>>FA> While I *could* rewrite all the code to use explicit functions, I
>>>FA> think, the resulting code would be much less clear.
>>>
>>>FA> Essentially what I want to do is conditionally import the RGtk2
>>> namespace.
>>>FA> Any suggestions?
>>>
>>> Maybe something along the line of
>>>
>>> if(is.function(try(RGtk2::gtkComboBoxEntryNewText))) {
>>> library(RGtk2)
>>>
>>>
>>> }
>>>
>>> ??
>>
>> I think the problem is that that puts the namespace on the user's search
>> list, which is what Felix wanted to avoid. He would like to import(RGtk2),
>> but only if it exists.
>>
>> There are conditionals allowed in NAMESPACE files, but I don't know if
>> they are allowed to be used to control imports. They are not well
>> documented -- they were called "experimental" when introduced in 1.9.0.
>>
>> If this is allowed, then something like
>>
>> if( "RGtk2" %in% rownames(installed.packages()) ) {
>> import(RGtk2)
>> }
>>
>> should work.
>
> I just did a little test, and it does appear to work if you use
> utils::installed.packages in the condition. And one clarification: those
> lines go into your NAMESPACE file, not into R code.
Many thanks Duncan, that is just what I wanted. The only problem now
is that it fails R CMD check:
* checking package dependencies ... ERROR
Namespace dependencies not required:
RGtk2
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grid error: protection stack overflow
I have isolated an error that can be reproduced by the following code.
The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the
try() code is ending up in the display list, or something?
library(grid)
library(lattice)
xyplot(1:100 ~ 1:100)
test <- try(downViewport("pageAnnotationVp"), silent = TRUE)
downViewport(trellis.vpname("toplevel"))
pushViewport(viewport(name = "pageAnnotationVp", yscale = c(1, 0)))
upViewport(0)
## resize device to trigger a couple of redraws...
Error: protect(): protection stack overflow
Enter a frame number, or 0 to exit
1: no.children()
2: ls(children, all.names = TRUE)
3: try(name)
4: tryCatch(expr, error = function(e) {
5: tryCatchList(expr, classes, parentenv, handlers)
6: tryCatchOne(expr, names, parentenv, handlers[[1]])
7: doTryCatch(return(expr), name, parentenv, handler)
> sessionInfo()
R version 2.8.0 Patched (2008-11-10 r46884)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] grid stats graphics grDevices utils datasets
methods base
other attached packages:
[1] lattice_0.17-15
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid error: protection stack overflow
For the record, a much better alternative to try(downViewport()) is
curVps <- grid.ls(grobs = FALSE, viewports = TRUE, print = FALSE)$name
if ("fooVp" %in% curVps) ...
2008/11/14 Felix Andrews <[EMAIL PROTECTED]>:
> I have isolated an error that can be reproduced by the following code.
> The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the
> try() code is ending up in the display list, or something?
>
> library(grid)
> library(lattice)
>
> xyplot(1:100 ~ 1:100)
> test <- try(downViewport("pageAnnotationVp"), silent = TRUE)
> downViewport(trellis.vpname("toplevel"))
> pushViewport(viewport(name = "pageAnnotationVp", yscale = c(1, 0)))
> upViewport(0)
>
> ## resize device to trigger a couple of redraws...
>
> Error: protect(): protection stack overflow
>
> Enter a frame number, or 0 to exit
> 1: no.children()
> 2: ls(children, all.names = TRUE)
> 3: try(name)
> 4: tryCatch(expr, error = function(e) {
> 5: tryCatchList(expr, classes, parentenv, handlers)
> 6: tryCatchOne(expr, names, parentenv, handlers[[1]])
> 7: doTryCatch(return(expr), name, parentenv, handler)
>
>
>> sessionInfo()
> R version 2.8.0 Patched (2008-11-10 r46884)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> attached base packages:
> [1] grid stats graphics grDevices utils datasets
> methods base
>
> other attached packages:
> [1] lattice_0.17-15
>
>
> --
> Felix Andrews / 安福立
> http://www.neurofractal.org/felix/
> 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
>
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Buggy trellis.focus() with xyplot ?
2008/11/20 Deepayan Sarkar <[EMAIL PROTECTED]>:
> On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
> <[EMAIL PROTECTED]> wrote:
>> Hi:
>>
>> (Tried to find a bug report about this issue, but was unable to find it, let
>> me know if this is a known issue)
>> I have been working on an interface to highlight xyplot panels on mouse
>> overs in JavaGD but I have stumbled with what seems to be a bug in
>> trellis.focus.
>> I am using R 2.8 with lattice 0.17-15
>>
>>
>> *** To replicate the bug:
>> 1.- display an xyplot. For example, from the xyplot help page:
>> library(lattice)
>> require(stats)
>> EE <- equal.count(ethanol$E, number=9, overlap=1/4)
>> ## Constructing panel functions on the fly; prepanel
>> xyplot(NOx ~ C | EE, data = ethanol,
>> prepanel = function(x, y) prepanel.loess(x, y, span = 1),
>> xlab = "Compression Ratio", ylab = "NOx (micrograms/J)",
>> panel = function(x, y) {
>> panel.grid(h=-1, v= 2)
>> panel.xyplot(x, y)
>> panel.loess(x,y, span=1)
>> },
>> aspect = "xy")
>> 2.- resize to window be rectangular and have large margins in the left hand
>> and right hand side.
>> 3.- run trellis.focus() and try to select the first or last panel, you
>> should observe that it does not select the right one.
>>
>> sidenotes:
>> There are other problems with the focus in JavaGD but I just wanted to
>> include a simple self contained example in this mail.
>> If you make the window smaller, trellis.focus() works fine, you have to make
>> it bigger than the initial size.
>>
>>
>> *** To Fix the bug:
>> I tried to fix this bug in interraction.R but I was unsuccesful.
>>
>> The problem should stem from the a bad calculation of the pads in the
>> follwoing lines :
>>leftPad <-
>> convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), "npc",
>> valueOnly = TRUE)
>>rightPad <-
>> convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), "npc",
>> valueOnly = TRUE)
>>topPad <-
>> convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), "npc",
>> valueOnly = TRUE)
>>botPad <-
>> convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), "npc",
>> valueOnly = TRUE)
>>
>> I was succesful in tweaking the follwing lines adding arbitrary constants to
>> make it work for a particular instance of a xyplot with a particular size of
>> a window
>> clickXScaled <- (as.numeric(clickLoc$x) - leftPad + Danielconstant1)
>> / (1 - leftPad - rightPad + Danielconstant1)
>>
>>clickYScaled <- (as.numeric(clickLoc$y) - botPad + Danielconstant2)
>> / (1 - botPad - topPad + Danielconstant3)
>> This is of course a useless fix, since you want the fix to work for any plot
>> with any window size, but I might be valuable information.
>>
>>
>> *** Questions:
>> - Is this a real bug ?
>> - Any suggestions for fixing it ?
>> - If it can't be fixed, is there a way around this bug ?
>> (For example, setting the margins to be zero and set a fixed size for the
>> xplot)
>
> It appears that the conversions used in the current implementation
> (contributed by Felix Andrews) don't work when aspect != "fill"
> (probably leading back to the use of 'respect = TRUE' in grid.layout).
Yep, my fault, didn't think it through.
> The right way to do this is to first go down to the subregion
> containing just the panels, and then locate the click location within
> it. But this requires a suitable viewport to be predefined.
>
> I have changed print.trellis to create such a dummy viewport
> (accessible by trellis.focus("figure")), and modified trellis.focus()
> to use it. I will test it a bit more before uploading a new version
> (and also give Felix a chance to see if this breaks anything in
It won't affect playwith; playwith now uses a different approach: a function
inViewport(x.px, y.px, viewport)
reports whether a click location in pixels is inside the given
viewport. I loop through each panel viewport and check whether the
click is inside.
> playwith etc.). To see if the fix works, you can try the svn copy at
>
> https://svn.r-project.org/R-packages/trunk/lattice
>
> -Deepayan
>
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Buggy trellis.focus() with xyplot ?
2008/11/20 Daniel Kornhauser <[EMAIL PROTECTED]>:
> Thanks a lot for taking this on guys !
>
> Some more background in case you are interested:
>
> I have almost a working version of focus for selecting a panel with mouse
> over in a stanalone Java application using an REngine I only have two
> issues:
>
> - trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes
> 1.5 seconds to unfocus, do you know any way to speed it up ?
Yep, redrawing R plots is slow. If you remove a grob the whole plot
needs to be redrawn. The solution is to use highlight = FALSE in the
trellis.focus() command. Obviously then there will be no visual
indication (red outline) of which panel is in focus. (If you need that
you could draw it yourself and then overpaint it with white to hide
it, maybe... the best solution would be to draw it using Java
graphics, rather than R graphics, and store a buffer, but I don't know
whether that's possible in your system).
>
> - the conversion problem that Deepayan referred too in the previous, but I
> guess that will be fixed soon. :-)
>
>
> I am working in a bastardized version of trellis.focus taking an x and y
> from an event handler (in Java, C, etc ...) which focuses and highlights the
> panel so the REngine instance can perform more operations on the selected
> panel.
> This would be very useful for easily creating GUI for interactive
> visualizations exploration of large multidimensional data sets using lattice
> and geared towards non programmers.
>
> I don't really know what I am getting into, so any advice would be welcomed.
Sounds similar to some of the functionality of the 'playwith' and/or
'latticist' packages. You might want to look at them. playwith is
built with GTK+.
>
> Daniel.
>
>
> 2008/11/19 Felix Andrews <[EMAIL PROTECTED]>
>>
>> 2008/11/20 Deepayan Sarkar <[EMAIL PROTECTED]>:
>> > On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser
>> > <[EMAIL PROTECTED]> wrote:
>> >> Hi:
>> >>
>> >> (Tried to find a bug report about this issue, but was unable to find
>> >> it, let
>> >> me know if this is a known issue)
>> >> I have been working on an interface to highlight xyplot panels on mouse
>> >> overs in JavaGD but I have stumbled with what seems to be a bug in
>> >> trellis.focus.
>> >> I am using R 2.8 with lattice 0.17-15
>> >>
>> >>
>> >> *** To replicate the bug:
>> >> 1.- display an xyplot. For example, from the xyplot help page:
>> >> library(lattice)
>> >> require(stats)
>> >> EE <- equal.count(ethanol$E, number=9, overlap=1/4)
>> >> ## Constructing panel functions on the fly; prepanel
>> >> xyplot(NOx ~ C | EE, data = ethanol,
>> >> prepanel = function(x, y) prepanel.loess(x, y, span = 1),
>> >> xlab = "Compression Ratio", ylab = "NOx (micrograms/J)",
>> >> panel = function(x, y) {
>> >> panel.grid(h=-1, v= 2)
>> >> panel.xyplot(x, y)
>> >> panel.loess(x,y, span=1)
>> >> },
>> >> aspect = "xy")
>> >> 2.- resize to window be rectangular and have large margins in the left
>> >> hand
>> >> and right hand side.
>> >> 3.- run trellis.focus() and try to select the first or last panel, you
>> >> should observe that it does not select the right one.
>> >>
>> >> sidenotes:
>> >> There are other problems with the focus in JavaGD but I just wanted to
>> >> include a simple self contained example in this mail.
>> >> If you make the window smaller, trellis.focus() works fine, you have to
>> >> make
>> >> it bigger than the initial size.
>> >>
>> >>
>> >> *** To Fix the bug:
>> >> I tried to fix this bug in interraction.R but I was unsuccesful.
>> >>
>> >> The problem should stem from the a bad calculation of the pads in the
>> >> follwoing lines :
>> >>leftPad <-
>> >> convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), "npc",
>> >> valueOnly = TRUE)
>> >>rightPad <-
>> >> convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]),
>> >> "npc",
>> >> valueOnly = TRUE)
>> >>topPad <-
>> >> convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), "npc",
>> >> valueOnly = T
[Rd] bug involving quote(); ghost in the machine
Hi list(...),
I've narrowed down a weird bug. It's like a ghost in the machine, in
that functions seem to remember things that they should not be able
to. In the example below, the result of the second (and subseqent)
calls depend on what was given in the first call.
foo <- function(given = NULL) {
callObj <- quote(callFunc())
if (!is.null(given))
callObj$given <- given
if (is.null(given))
callObj$default <- TRUE
callObj
}
foo()
# callFunc(default = TRUE)
foo(given = TRUE)
# callFunc(default = TRUE, given = TRUE)
Note, if the first call was something different, the result is different:
foo("blah blah")
# callFunc(given = "blah blah")
foo(given = TRUE)
# callFunc(given = TRUE)
foo()
# callFunc(given = "blah blah", default = TRUE)
So on subsequent calls, callObj is being initialised to its final
value from the first call. You can actually see this here:
body(foo)[[2]]
# callObj <- quote(callFunc(given = "blah blah"))
The problem seems to be related to quote(callFunc()), because if you
replace it with call("callFunc"), everything works as expected:
foo.ok <- function(given = NULL) {
callObj <- call("callFunc")
if (!is.null(given))
callObj$given <- given
if (is.null(given))
callObj$default <- TRUE
callObj
}
foo.ok()
# callFunc(default = TRUE)
foo.ok(given = TRUE)
# callFunc(given = TRUE)
> sessionInfo()
R version 2.9.0 Under development (unstable) (2009-01-04 r47462)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] interrupting R from a GUI
list(...), I am looking for a way to interrupt R from a callback: specifically, to interrupt plotting (typically on a cairoDevice, but would be good if it worked with other devices too). Of course, one can interrupt R nicely from the console with Ctrl-C (or Esc in Rgui), but I need to do it from a GUI. Callbacks run in a new thread, so obviously stop() etc will not work. I tried to look into how Rgui does it... https://svn.r-project.org/R/trunk/src/gnuwin32/psignal.c ?...but it is beyond me. Alternatively, might there be a way to tell the cairoDevice widget to stop drawing, somehow? Any help would be appreciated. -Felix -- Felix Andrews / 安福立 http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] interrupting R from a GUI
2009/1/16 Prof Brian Ripley :
> On Fri, 16 Jan 2009, Felix Andrews wrote:
>
>> list(...),
>>
>> I am looking for a way to interrupt R from a callback: specifically,
>> to interrupt plotting (typically on a cairoDevice, but would be good
>> if it worked with other devices too). Of course, one can interrupt R
>> nicely from the console with Ctrl-C (or Esc in Rgui), but I need to do
>> it from a GUI. Callbacks run in a new thread, so obviously stop() etc
>> will not work. I tried to look into how Rgui does it...
>> https://svn.r-project.org/R/trunk/src/gnuwin32/psignal.c
>
> Actually no, Rgui does not use that code (but Rterm does).
>
>> ?...but it is beyond me.
>
> In detail this is OS-specific, but what the front-ends do is to set a flag
> or send a signal to R: look e.g. at rterm.c:
>
> static void my_onintr(int nSig)
> {
> UserBreak = 1;
> PostThreadMessage(mainThreadId,0,0,0);
> }
>
> or onintr in errors.c (which is called when UserBreak = 1, from the ain
> thread). In due course R_interrupts_pending gets set and then at an
> appropriate spot R stops and unwinds the currrent evaluations.
>
> The relevant Windows code is even in 'Writing R Extensions'.
>
> So depending on your OS you can raise a signal or set a flag. You can raise
> a signal on Windows too, so 'raise' is the most portable solution -- but
> beware that threading models differ.
Dear Professor Ripley,
Many thanks for your information-rich response.
I have not looked at serious C code before, so I find the R source
code quite confusing.
This is what I have come up with (as my package's src/interrupt.c):
#include
#ifdef WIN32
extern int UserBreak;
#endif
void do_interrupt(void)
{
#ifdef WIN32
UserBreak = 1;
//raise(SIGBREAK);
#else
raise(SIGINT);
#endif
}
This seems to work under Rgui and Rterm on windows XP. I have not
tested it on linux or macOS. Does it look reasonable?
>
>> Any help would be appreciated.
>>
>> -Felix
>>
>> --
>> Felix Andrews / 安福立
>> http://www.neurofractal.org/felix/
>
> [Those seeking technical advice will increase their chances of help by
> giving their affiliation(s) or at least explaining the purpose of the
> request so that potential helpers know it is non-commercial. You may not
> get the benefit of the doubt next time.]
Fair enough; this is for the playwith package, which is GPL'd, and
(sadly) has no commercial links or prospects. I am affiliated in
various ways with the Australian National University.
--
Felix Andrews / 安福立
http://www.neurofractal.org/felix/
3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
