Re: [Rd] plot.lm: "Cook's distance" label can overplot point labels
Actually, the contours and the smooth are currently printed with
col=2. This prints satisfactorily in grayscale.Colours ("orange"
and "darkred" as well as col=2) are also used in termplot.
Does the stricture against "colour" extend to grayscale? Does it
apply to lines as well as text?
John Maindonald email: john.maindon...@anu.edu.au
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
On 19/02/2009, at 5:58 PM, Prof Brian Ripley wrote:
On Wed, 18 Feb 2009, John Fox wrote:
Dear John,
-Original Message-
From: John Maindonald [mailto:john.maindon...@anu.edu.au]
Sent: February-18-09 4:57 PM
To: John Fox
Cc: 'Martin Maechler'; r-devel@r-project.org
Subject: Re: [Rd] plot.lm: "Cook's distance" label can overplot
point
labels
Dear John -
The title above the graph is also redundant for the first of the
plots; do we want to be totally consistent? I am not sure.
Why not? "A foolish consistency is the hobgoblin of little minds,"
but maybe
this isn't a foolish consistency.
It occurs to me that the text "Cook's distance", as well as the
contours, might be in red.
That would provide a nice visual cue (for those who aren't colour
blind).
Or using a black-and-white device. We have not hitherto assumed a
colour device in 'stats' graphics, and given how often they are
printed I don't think we want to start.
As so often, it seems that what looks good is in the eye of the
beholder. If the two of you can agree on something that you both
see is a definite improvement, please provide a patch and examples
to try to persuade everyone else. (As a Wishlist item on R-bugs, so
it gets recorded.)
Best,
John
Regards
John.
John Maindonald email: john.maindon...@anu.edu.au
phone : +61 2 (6125)3473fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
On 18/02/2009, at 12:27 PM, John Fox wrote:
Dear John,
It occurs to me that the title above the graph, "Residuals vs.
Leverage," is
entirely redundant since the x-axis is labelled "Leverage" and
the y-
axis
"Studentized residuals." Why not use the title above the graph for
"Cook's
distance countours"?
Regards,
John
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org
]
On
Behalf Of John Maindonald
Sent: February-17-09 5:54 PM
To: r-devel@r-project.org
Cc: Martin Maechler
Subject: [Rd] plot.lm: "Cook's distance" label can overplot point
labels
The following code demonstrates an annoyance with plot.lm():
library(DAAGxtras)
x11(width=3.75, height=4)
nihills.lm <- lm(log(time) ~ log(dist) + log(climb), data =
nihills)
plot(nihills.lm, which=5)
OR try the following
xy <- data.frame(x=c(3,1:5), y=c(-2, 1:5))
plot(lm(y ~ x, data=xy), which=5)
The "Cook's distance" text overplots the label for the point
with the
smallest residual. This is an issue when the size of the plot is
much
less than the default, and the pointsize is not reduced
proportionately.
I suggest the following:
xx <- hii
xx[xx >= 1] <- NA
## Insert new code
fracht <- (1.25*par()$cin[2])/par()$pin[2]
ylim[1] <- ylim[1] - diff(ylim)*max(0, fracht-0.04)
## End insert new code
plot(xx, rsp, xlim = c(0, max(xx, na.rm = TRUE)),
ylim = ylim, main = main, xlab = "Leverage",
ylab = ylab5, type = "n", ...)
Then, about 15 lines further down, replace
legend("bottomleft", legend = "Cook's distance",
lty = 2, col = 2, bty = "n")
by
legend("bottomleft", legend = "Cook's distance",
lty = 2, col = 2, bty = "n", y.intersp=0.5)
If this second change is not made, then one wants fracht <-
(1.5*par()
$cin[2])/par()$pin[2]
I prefer the "Cook's distance" text to be a bit closer to the x-
axis,
as it separates it more clearly from any point labels.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inaccurate result for 0. (PR#13538)
Full_Name: Attila Lengyel Version: 2.8.0 OS: WinXP Submission from: (NULL) (81.182.224.160) > -0.3+0.1+0.1+0.1 [1] 2.775558e-17 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate result for 0. (PR#13538)
Hmmm, the favorite. http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f G. On Wed, Feb 18, 2009 at 9:15 PM, wrote: > Full_Name: Attila Lengyel > Version: 2.8.0 > OS: WinXP > Submission from: (NULL) (81.182.224.160) > > >> -0.3+0.1+0.1+0.1 > [1] 2.775558e-17 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabor Csardi UNIL DGM __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate result for 0. (PR#13538)
FAQ 7.31 On Wed, 18 Feb 2009, lengyel...@gmail.com wrote: Full_Name: Attila Lengyel Version: 2.8.0 OS: WinXP Submission from: (NULL) (81.182.224.160) -0.3+0.1+0.1+0.1 [1] 2.775558e-17 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate result for 0. (PR#13538)
On 18/02/2009 3:15 PM, lengyel...@gmail.com wrote: Full_Name: Attila Lengyel Version: 2.8.0 OS: WinXP Submission from: (NULL) (81.182.224.160) -0.3+0.1+0.1+0.1 [1] 2.775558e-17 This is not a bug, it's FAQ 7.31. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inaccurate result for 0. (PR#13538)
Please read documentation and how to submit busg before you submit bugs to the bug repository. See FAQ "Why doesn't R think these numbers are equal?". Uwe Ligges lengyel...@gmail.com wrote: > Full_Name: Attila Lengyel > Version: 2.8.0 > OS: WinXP > Submission from: (NULL) (81.182.224.160) > > >> -0.3+0.1+0.1+0.1 > [1] 2.775558e-17 > > __ > 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] vignette compilation times
Dear All I am preparing a number of vignettes that require a very long time to process with Sweave. The longest one takes 10 hours. I love the weaver package! Is a package that includes such a computationally intensive vignette acceptable on CRAN? Are there any guidelines here? -- Robin K. S. Hankin Uncertainty Analyst University of Cambridge 19 Silver Street Cambridge CB3 9EP 01223-764877 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
Two ideas: 1) A library for interactive plots in R R lacks functionality that would allow displaying of interactive plots with two distinct functionalities: zooming and panning. This functionality is extremely important for the analysis of large, high frequency, data sets spanning over large ranges (in time as well). The functionality should acknowledge Axis methods in callbacks on rescale (so that it could be extended to user-specific classes for axis generation) and should have a native C interface to R (i.e. no Java, but such cross platform widgets like GTK or QT or anything similar that does not require heavy-weight add-ons). GTK has been used successfully from within R in many applications (RGtk, rgobby, EBImage etc) on both *nix and Windows, and thus could be a preferential option, it is also extremely easy to integrate into R. The existing tools (e.g. iplots) are slow, unstable and lack support for time/date plots (or actually any non-standard axes) and they are all Java. We are looking into stanard xy-plots as well as image and 3D plots. Obviously one can think of further interactivity, but this would be too much for the Summer of Code project. A good prototype would already be a step forward. 2) Cross platform GUI debugger, preferably further Eclipse integration (beyond StatET capabilities) Tibco has recently released the S+ workbench for eclipse which has a reasonable support for non-command line debugging. In the R community, the StatET eclipse plugin mimics a lot of code development functionality of S+ workbench, but has poor support for in-line execution of R sessions in eclipse and does not have debugging capabilities. Supporting this project further, or developing a GUI debugger independent of eclipse, are both acceptable options. The debugger should allow breakpoints, variable views etc. For both of the above, our interest is mostly on the Linux side, but one should look into cross-platform solutions. Regards, Oleg Dr Oleg Sklyar Research Technologist AHL / Man Investments Ltd +44 (0)20 7144 3107 oskl...@maninvestments.com > -Original Message- > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Friedrich Leisch > Sent: 18 February 2009 22:54 > To: r-devel@r-project.org > Cc: manuel.eugs...@stat.uni-muenchen.de > Subject: [Rd] Google Summer of Code 2009 > > > Hi, > > in approximately one months time mentoring institutions can propose > projects for the Google Summer of Code 2009, see > > http://code.google.com/soc/ > > Last year the R Foundation succesfully participated with 4 projects, > see http://www.r-project.org/SoC08/ for details. We want to > participate again this year. Our project proposals will be managed by > Manuel Eugster (email address in CC). Manuel is one of my PhD students > and mentored the Roxygen project last year. This mail is mainly > intended to make you aware of the program, Manuel will send a followup > email with more technical details in the next days. > > In this phase we are looking for potential mentors who can offer > interesting projects to students. I don't think that we will get much > more than 4-6 projects, so don't be disappointed if you propose > something and don't get selected. > > There are two selection steps involved: (a) The R Foundation has to > compile an official "ideas list" of projects, for which students can > apply. Last year we had 8 of those. After that, we (b) get a certain > number of slots from Google (4 last year) and all prospective project > mentors can vote on which projects actually get funding. > > Currently we are looking for good ideas for phase (a). I give no > guarantees that all ideas will get on our official ideas list, what we > pick depends on the number of submissions and topics, respectively. We > want to make sure to have a broad range of themes, it is unlikely, > that we will, e.g., pick 10 database projects. Also keep in mind that > students have only three months time. This is not a research exercise > for the students, you should have a rough idea what needs to be done. > > Last year we had a majority of "infrastructure projects", and only few > with focus on statistical algorithms. We got a lot of applications for > the latter, so don't hesitate to formulate projects in that > direction. Important infrastructure may get precedence over > specialized algorithms, though, because the whole community can benfit > from those. But that will be a decision in phase (b), and we are not > there yet. > > Please don't send any ideas to me right now, wait for the above > mentioned email by Manuel on the technical details for idea > submission. > > Best, > Fritz > > -- > -- > - > Prof. Dr. Friedrich Leisch > > Institut für Statistik Tel: (+49 89) > 2180 3165 > Ludwig-Maximilians-Universität Fax: (+49 89) > 2180 5308 > L
Re: [Rd] Inaccurate result for 0. (PR#13538)
Gábor Csárdi wrote: > Hmmm, the favorite. > > http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f > hmm, an interesting quote: " To quote from “The Elements of Programming Style” by Kernighan and Plauger: /10.0 times 0.1 is hardly ever 1.0/. " so here's one example where 10.0 times 0.1 *is* 1.0: perl -Mbignum -le 'print (10.0 * 0.1 == 1.0)' # 1, for true not an isolated idiosyncrazy, for that matter. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
thanks for this clarification Uwe Could I include the r_env_cache/ directory in the package and then assume that the CRAN checks use Sweave( , driver=weaver()) in which case the process takes about 10 seconds? rksh Uwe Ligges wrote: Robin Hankin wrote: Dear All I am preparing a number of vignettes that require a very long time to process with Sweave. The longest one takes 10 hours. I love the weaver package! Is a package that includes such a computationally intensive vignette acceptable on CRAN? Are there any guidelines here? Robin, please try to keep a package below 5 minutes check time. You know, it's hard to perform daily checks for 1700 packages if just one already runs for 10 hours. In reasonable circumstances, we do have exclude lists, but it probably does not make sense to provide that computational intensive vignettes. Perhaps you can provide some intermediate results in form of Rdata files in order to reduce runtime of your vignette's creation (and checks!). Best wishes, Uwe -- Robin K. S. Hankin Uncertainty Analyst University of Cambridge 19 Silver Street Cambridge CB3 9EP 01223-764877 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
Robin Hankin wrote: Dear All I am preparing a number of vignettes that require a very long time to process with Sweave. The longest one takes 10 hours. I love the weaver package! Is a package that includes such a computationally intensive vignette acceptable on CRAN? Are there any guidelines here? Robin, please try to keep a package below 5 minutes check time. You know, it's hard to perform daily checks for 1700 packages if just one already runs for 10 hours. In reasonable circumstances, we do have exclude lists, but it probably does not make sense to provide that computational intensive vignettes. Perhaps you can provide some intermediate results in form of Rdata files in order to reduce runtime of your vignette's creation (and checks!). Best wishes, Uwe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot.lm: "Cook's distance" label can overplot point labels
Dear John and Brian,
My point about colour-blindness was partly tongue-in-cheek, but I think that
it's a bad choice to have the second and third colours in the default
palette as red and green.
Regards,
John
> -Original Message-
> From: John Maindonald [mailto:john.maindon...@anu.edu.au]
> Sent: February-19-09 2:54 AM
> To: Prof Brian Ripley
> Cc: John Fox; r-devel@r-project.org; 'Martin Maechler'
> Subject: Re: [Rd] plot.lm: "Cook's distance" label can overplot point
labels
>
> Actually, the contours and the smooth are currently printed with
> col=2. This prints satisfactorily in grayscale.Colours ("orange"
> and "darkred" as well as col=2) are also used in termplot.
>
> Does the stricture against "colour" extend to grayscale? Does it
> apply to lines as well as text?
>
> John Maindonald email: john.maindon...@anu.edu.au
> phone : +61 2 (6125)3473fax : +61 2(6125)5549
> Centre for Mathematics & Its Applications, Room 1194,
> John Dedman Mathematical Sciences Building (Building 27)
> Australian National University, Canberra ACT 0200.
>
>
> On 19/02/2009, at 5:58 PM, Prof Brian Ripley wrote:
>
> > On Wed, 18 Feb 2009, John Fox wrote:
> >
> >> Dear John,
> >>
> >>> -Original Message-
> >>> From: John Maindonald [mailto:john.maindon...@anu.edu.au]
> >>> Sent: February-18-09 4:57 PM
> >>> To: John Fox
> >>> Cc: 'Martin Maechler'; r-devel@r-project.org
> >>> Subject: Re: [Rd] plot.lm: "Cook's distance" label can overplot
> >>> point
> >> labels
> >>>
> >>> Dear John -
> >>> The title above the graph is also redundant for the first of the
> >>> plots; do we want to be totally consistent? I am not sure.
> >>
> >> Why not? "A foolish consistency is the hobgoblin of little minds,"
> >> but maybe
> >> this isn't a foolish consistency.
> >>
> >>>
> >>> It occurs to me that the text "Cook's distance", as well as the
> >>> contours, might be in red.
> >>
> >> That would provide a nice visual cue (for those who aren't colour
> >> blind).
> >
> > Or using a black-and-white device. We have not hitherto assumed a
> > colour device in 'stats' graphics, and given how often they are
> > printed I don't think we want to start.
> >
> > As so often, it seems that what looks good is in the eye of the
> > beholder. If the two of you can agree on something that you both
> > see is a definite improvement, please provide a patch and examples
> > to try to persuade everyone else. (As a Wishlist item on R-bugs, so
> > it gets recorded.)
> >
> >>
> >> Best,
> >> John
> >>
> >>> Regards
> >>> John.
> >>>
> >>> John Maindonald email: john.maindon...@anu.edu.au
> >>> phone : +61 2 (6125)3473fax : +61 2(6125)5549
> >>> Centre for Mathematics & Its Applications, Room 1194,
> >>> John Dedman Mathematical Sciences Building (Building 27)
> >>> Australian National University, Canberra ACT 0200.
> >>>
> >>>
> >>> On 18/02/2009, at 12:27 PM, John Fox wrote:
> >>>
> Dear John,
>
> It occurs to me that the title above the graph, "Residuals vs.
> Leverage," is
> entirely redundant since the x-axis is labelled "Leverage" and
> the y-
> axis
> "Studentized residuals." Why not use the title above the graph for
> "Cook's
> distance countours"?
>
> Regards,
> John
>
> > -Original Message-
> > From: r-devel-boun...@r-project.org
> >> [mailto:r-devel-boun...@r-project.org
> > ]
> On
> > Behalf Of John Maindonald
> > Sent: February-17-09 5:54 PM
> > To: r-devel@r-project.org
> > Cc: Martin Maechler
> > Subject: [Rd] plot.lm: "Cook's distance" label can overplot point
> > labels
> >
> > The following code demonstrates an annoyance with plot.lm():
> >
> > library(DAAGxtras)
> > x11(width=3.75, height=4)
> > nihills.lm <- lm(log(time) ~ log(dist) + log(climb), data =
> > nihills)
> > plot(nihills.lm, which=5)
> >
> > OR try the following
> > xy <- data.frame(x=c(3,1:5), y=c(-2, 1:5))
> > plot(lm(y ~ x, data=xy), which=5)
> >
> > The "Cook's distance" text overplots the label for the point
> > with the
> > smallest residual. This is an issue when the size of the plot is
> > much
> > less than the default, and the pointsize is not reduced
> > proportionately.
> >
> >
> > I suggest the following:
> >xx <- hii
> >xx[xx >= 1] <- NA
> > ## Insert new code
> >fracht <- (1.25*par()$cin[2])/par()$pin[2]
> >ylim[1] <- ylim[1] - diff(ylim)*max(0, fracht-0.04)
> > ## End insert new code
> >plot(xx, rsp, xlim = c(0, max(xx, na.rm = TRUE)),
> > ylim = ylim, main = main, xlab = "Leverage",
> > ylab = ylab5, type = "n", ...)
> >
> > Then, about 15 lines further down, replace
> > legend("bottomleft", legend = "Cook's distance",
> > lty = 2, col = 2, bty = "n")
> >
> > by
> > legend("b
[Rd] cpu bound cases
I'm considering some things AMD could do to accelerate R using GPU processors. In an internal discussion I was asked "Are there interesting R computations which are currently cpu bound?" I'm sure there are lots but I'd like to be able to name some real world cases. Does any one know of some good examples? Thanks Norm Rubin [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
On Feb 19, 2009, at 6:38 , Sklyar, Oleg (London) wrote: Two ideas: 1) A library for interactive plots in R R lacks functionality that would allow displaying of interactive plots with two distinct functionalities: zooming and panning. This functionality is extremely important for the analysis of large, high frequency, data sets spanning over large ranges (in time as well). The functionality should acknowledge Axis methods in callbacks on rescale (so that it could be extended to user-specific classes for axis generation) and should have a native C interface to R (i.e. no Java, but such cross platform widgets like GTK or QT or anything similar that does not require heavy-weight add-ons). GTK has been used successfully from within R in many applications (RGtk, rgobby, EBImage etc) on both *nix and Windows, and thus could be a preferential option, it is also extremely easy to integrate into R. The existing tools (e.g. iplots) are slow, unstable and lack support for time/date plots (or actually any non-standard axes) and they are all Java. We are looking into stanard xy-plots as well as image and 3D plots. Obviously one can think of further interactivity, but this would be too much for the Summer of Code project. A good prototype would already be a step forward. If primitive 3d scatterplot interactivity is all you want, go with rggobi. It's GTK and has all this already and much more. However, ggobi also shows why GTK is not a good choice for general interactive graphics toolkit - it [GTK] is slow and lacks reasonable graphics support. OpenGL is IMHO a better way to go since IG don't really leverage any of the widgets (you get them for free via R widgets packages anyway) and OpenGL gives you excellent speed, alpha-support and anti-aliasing etc. As you can imagine I don't agree with most of your statements above and I'm happy to discuss them in a separate thread. Just as an aside iPlots 3.0 (announced for useR!/DSC) are no longer Java based and have a native C interface. Cheers, S 2) Cross platform GUI debugger, preferably further Eclipse integration (beyond StatET capabilities) Tibco has recently released the S+ workbench for eclipse which has a reasonable support for non-command line debugging. In the R community, the StatET eclipse plugin mimics a lot of code development functionality of S+ workbench, but has poor support for in-line execution of R sessions in eclipse and does not have debugging capabilities. Supporting this project further, or developing a GUI debugger independent of eclipse, are both acceptable options. The debugger should allow breakpoints, variable views etc. For both of the above, our interest is mostly on the Linux side, but one should look into cross-platform solutions. Regards, Oleg Dr Oleg Sklyar Research Technologist AHL / Man Investments Ltd +44 (0)20 7144 3107 oskl...@maninvestments.com -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Friedrich Leisch Sent: 18 February 2009 22:54 To: r-devel@r-project.org Cc: manuel.eugs...@stat.uni-muenchen.de Subject: [Rd] Google Summer of Code 2009 Hi, in approximately one months time mentoring institutions can propose projects for the Google Summer of Code 2009, see http://code.google.com/soc/ Last year the R Foundation succesfully participated with 4 projects, see http://www.r-project.org/SoC08/ for details. We want to participate again this year. Our project proposals will be managed by Manuel Eugster (email address in CC). Manuel is one of my PhD students and mentored the Roxygen project last year. This mail is mainly intended to make you aware of the program, Manuel will send a followup email with more technical details in the next days. In this phase we are looking for potential mentors who can offer interesting projects to students. I don't think that we will get much more than 4-6 projects, so don't be disappointed if you propose something and don't get selected. There are two selection steps involved: (a) The R Foundation has to compile an official "ideas list" of projects, for which students can apply. Last year we had 8 of those. After that, we (b) get a certain number of slots from Google (4 last year) and all prospective project mentors can vote on which projects actually get funding. Currently we are looking for good ideas for phase (a). I give no guarantees that all ideas will get on our official ideas list, what we pick depends on the number of submissions and topics, respectively. We want to make sure to have a broad range of themes, it is unlikely, that we will, e.g., pick 10 database projects. Also keep in mind that students have only three months time. This is not a research exercise for the students, you should have a rough idea what needs to be done. Last year we had a majority of "infrastructure projects", and only few with focus on s
Re: [Rd] Google Summer of Code 2009
Simon, I would not like to take it offline as I disagree with your points and think it is fair to let other users know why. To make it clear first, I am most interested in 2D, not 3D plots, and rgobbi is not a good enough solution, unfortunately. 1) I spent loads of time looking for good, if any at all, interactive graphics packages for R. There are hardly many, and apart from rgl there are no good ones as I see it. I do accept that this can be subjective, but I think many people will share my opinion. 2) With respect to iplots: http://cran.r-project.org/web/packages/iplots/index.html states: Version:1.1-3 Depends:R (≥ 1.5.0), methods, rJava (≥ 0.5-0) http://www.rosuda.org/iplots/ states: News: * 2007/08/07 Released iplots_1.1-1 on CRAN... There might be version 3 available somewhere, but it is not obvious where and the above one is Java based. I have tried the above version about 4 months ago -- it was slow, unstable and did not have any support for time axis at all. If I find it, I will give it a try and will be able to post corresponding comments. 2) rggobi is not a solution for 2D graphics at all and this is what is missing in R. I would not mention rgobbi myself having had no look at it first. However, if somebody works on interactive 2D plots, there is no reason why this person should think of 3D as well to have all in one framework. 3) I have a prototype using gtkdatabox for very fast interactive plots in R using GTK, but it is limited by the capabilities of the gtkdatabox widget, not that of R or GTK as such. I do think there is a need for an interactive graphics package for R. Dr Oleg Sklyar Research Technologist AHL / Man Investments Ltd +44 (0)20 7144 3107 oskl...@maninvestments.com > -Original Message- > From: Simon Urbanek [mailto:simon.urba...@r-project.org] > Sent: 19 February 2009 14:34 > To: Sklyar, Oleg (London) > Cc: Friedrich Leisch; r-devel@r-project.org; > manuel.eugs...@stat.uni-muenchen.de > Subject: Re: [Rd] Google Summer of Code 2009 > > > On Feb 19, 2009, at 6:38 , Sklyar, Oleg (London) wrote: > > > Two ideas: > > > > 1) A library for interactive plots in R > > > > R lacks functionality that would allow displaying of interactive > > plots with two distinct functionalities: zooming and panning. This > > functionality is extremely important for the analysis of > large, high > > frequency, data sets spanning over large ranges (in time as well). > > The functionality should acknowledge Axis methods in callbacks on > > rescale (so that it could be extended to user-specific classes for > > axis generation) and should have a native C interface to R > (i.e. no > > Java, but such cross platform widgets like GTK or QT or anything > > similar that does not require heavy-weight add-ons). GTK has been > > used successfully from within R in many applications (RGtk, > rgobby, > > EBImage etc) on both *nix and Windows, and thus could be a > > preferential option, it is also extremely easy to integrate > into R. > > The existing tools (e.g. iplots) are slow, unstable and > lack support > > for time/date plots (or actually any non-standard axes) and > they are > > all Java. We are looking into stanard xy-plots as well as > image and > > 3D plots. Obviously one can think of further interactivity, > but this > > would be too much for the Summer of Code project. A good prototype > > would already be a step forward. > > > > If primitive 3d scatterplot interactivity is all you want, go with > rggobi. It's GTK and has all this already and much more. However, > ggobi also shows why GTK is not a good choice for general > interactive > graphics toolkit - it [GTK] is slow and lacks reasonable graphics > support. OpenGL is IMHO a better way to go since IG don't really > leverage any of the widgets (you get them for free via R widgets > packages anyway) and OpenGL gives you excellent speed, alpha-support > and anti-aliasing etc. > > As you can imagine I don't agree with most of your statements above > and I'm happy to discuss them in a separate thread. Just as an aside > iPlots 3.0 (announced for useR!/DSC) are no longer Java based > and have > a native C interface. > > Cheers, > S > > > > 2) Cross platform GUI debugger, preferably further Eclipse > > integration (beyond StatET capabilities) > > > > Tibco has recently released the S+ workbench for eclipse > which has a > > reasonable support for non-command line debugging. In the R > > community, the StatET eclipse plugin mimics a lot of code > > development functionality of S+ workbench, but has poor > support for > > in-line execution of R sessions in eclipse and does not have > > debugging capabilities. Supporting this project further, or > > developing a GUI debugger independent of eclipse, are both > > acceptable options. The debugger should allow breakpoints, > variable > > views etc. > > > > For both of t
Re: [Rd] Google Summer of Code 2009
On Thu, Feb 19, 2009 at 3:47 PM, Sklyar, Oleg (London) wrote: > I do think there is a need for an interactive graphics package for R. > There are also the GTK-based playwith, and latticist; unsure though whether they fit your requirements. Liviu -- Do you know how to read? http://www.alienetworks.com/srtest.cfm Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
Thanks for pointing out. playwith looks quite interesting
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Liviu Andronic [mailto:landronim...@gmail.com]
> Sent: 19 February 2009 15:11
> To: Sklyar, Oleg (London)
> Cc: Simon Urbanek; Friedrich Leisch;
> manuel.eugs...@stat.uni-muenchen.de; r-devel@r-project.org
> Subject: Re: [Rd] Google Summer of Code 2009
>
> On Thu, Feb 19, 2009 at 3:47 PM, Sklyar, Oleg (London)
> wrote:
> > I do think there is a need for an interactive graphics
> package for R.
> >
> There are also the GTK-based playwith, and latticist; unsure though
> whether they fit your requirements.
> Liviu
>
>
>
> --
> Do you know how to read?
> http://www.alienetworks.com/srtest.cfm
> Do you know how to write?
> http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
>
**
Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
Well, for the first idea, isn't it easy enough to fulfill zooming or
panning using getGraphicsEvent() in the grDevices package? For example
(using keys +/-/Left/Right/Up/Down/* to zoom and pan):
##
# a demo for zooming and panning in R graphics
# by Yihui Xie Feb 20, 2009
##
# a large number of points
plot(x <- rnorm(5000), y <- rnorm(5000), xlab = "x", ylab = "y")
xylim <- c(range(x), range(y))
zoom <- function(d, speed = 0.05) {
rx <- speed * (xylim[2] - xylim[1])
ry <- speed * (xylim[4] - xylim[3])
# global assignment '<<-' here!
xylim <<- xylim + d * c(rx, -rx, ry, -ry)
plot(x, y, xlim = xylim[1:2], ylim = xylim[3:4])
NULL
}
# Key `+`: zoom in; `-`: zoom out
# Left, Right, Up, Down: self-explaining
# `*`: reset
# Press other keys to quit
keybd <- function(key) {
switch(key, `+` = zoom(1), `-` = zoom(-1), Left = zoom(c(-1,
1, 0, 0)), Right = zoom(c(1, -1, 0, 0)), Up = zoom(c(0,
0, 1, -1)), Down = zoom(c(0, 0, -1, 1)), `*` = plot(x,
y), "Quit the program")
}
getGraphicsEvent(onKeybd = keybd)
##
Regards,
Yihui
--
Yihui Xie
Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
Mobile: +86-15810805877
Homepage: http://www.yihui.name
School of Statistics, Room 1037, Mingde Main Building,
Renmin University of China, Beijing, 100872, China
On Thu, Feb 19, 2009 at 7:38 PM, Sklyar, Oleg (London)
wrote:
> Two ideas:
>
> 1) A library for interactive plots in R
>
> R lacks functionality that would allow displaying of interactive plots with
> two distinct functionalities: zooming and panning. This functionality is
> extremely important for the analysis of large, high frequency, data sets
> spanning over large ranges (in time as well). The functionality should
> acknowledge Axis methods in callbacks on rescale (so that it could be
> extended to user-specific classes for axis generation) and should have a
> native C interface to R (i.e. no Java, but such cross platform widgets like
> GTK or QT or anything similar that does not require heavy-weight add-ons).
> GTK has been used successfully from within R in many applications (RGtk,
> rgobby, EBImage etc) on both *nix and Windows, and thus could be a
> preferential option, it is also extremely easy to integrate into R. The
> existing tools (e.g. iplots) are slow, unstable and lack support for
> time/date plots (or actually any non-standard axes) and they are all Java. We
> are looking into stanard xy-plots as well as image and 3D plots. Obviously
> one can think of further interactivity, but this would be too much for the
> Summer of Code project. A good prototype would already be a step forward.
>
> 2) Cross platform GUI debugger, preferably further Eclipse integration
> (beyond StatET capabilities)
>
> Tibco has recently released the S+ workbench for eclipse which has a
> reasonable support for non-command line debugging. In the R community, the
> StatET eclipse plugin mimics a lot of code development functionality of S+
> workbench, but has poor support for in-line execution of R sessions in
> eclipse and does not have debugging capabilities. Supporting this project
> further, or developing a GUI debugger independent of eclipse, are both
> acceptable options. The debugger should allow breakpoints, variable views etc.
>
> For both of the above, our interest is mostly on the Linux side, but one
> should look into cross-platform solutions.
>
> Regards,
> Oleg
>
> Dr Oleg Sklyar
> Research Technologist
> AHL / Man Investments Ltd
> +44 (0)20 7144 3107
> oskl...@maninvestments.com
>
>> -Original Message-
>> From: r-devel-boun...@r-project.org
>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Friedrich Leisch
>> Sent: 18 February 2009 22:54
>> To: r-devel@r-project.org
>> Cc: manuel.eugs...@stat.uni-muenchen.de
>> Subject: [Rd] Google Summer of Code 2009
>>
>>
>> Hi,
>>
>> in approximately one months time mentoring institutions can propose
>> projects for the Google Summer of Code 2009, see
>>
>> http://code.google.com/soc/
>>
>> Last year the R Foundation succesfully participated with 4 projects,
>> see http://www.r-project.org/SoC08/ for details. We want to
>> participate again this year. Our project proposals will be managed by
>> Manuel Eugster (email address in CC). Manuel is one of my PhD students
>> and mentored the Roxygen project last year. This mail is mainly
>> intended to make you aware of the program, Manuel will send a followup
>> email with more technical details in the next days.
>>
>> In this phase we are looking for potential mentors who can offer
>> interesting projects to students. I don't think that we will get much
>> more than 4-6 projects, so don't be disappointed if you propose
>> something and don't get selected.
>>
>> There are two selection steps involved: (a) Th
Re: [Rd] Google Summer of Code 2009
Dear Yihui,
I am sure there are many possibilities available, but I am not looking for a
hack and rather for a versatile high-quality solution. It solution should be
fast, reliable and developed to a high standard. Moreover, on my X11 RHEL5
x86_64 I get the following:
> getGraphicsEvent(onKeybd = keybd)
Error in getGraphicsEvent(onKeybd = keybd) :
graphics device does not support graphics events
Furthermore, one could think of a library displaying multiple plots, for
multivariate data, allowing simultaneous zoom into all of the plots.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Yihui Xie [mailto:xieyi...@gmail.com]
> Sent: 19 February 2009 16:20
> To: Sklyar, Oleg (London)
> Cc: Liviu Andronic; Friedrich Leisch; Simon Urbanek;
> manuel.eugs...@stat.uni-muenchen.de; r-devel@r-project.org
> Subject: Re: [Rd] Google Summer of Code 2009
>
> Well, for the first idea, isn't it easy enough to fulfill zooming or
> panning using getGraphicsEvent() in the grDevices package? For example
> (using keys +/-/Left/Right/Up/Down/* to zoom and pan):
>
> ##
> # a demo for zooming and panning in R graphics
> # by Yihui Xie Feb 20, 2009
> ##
> # a large number of points
> plot(x <- rnorm(5000), y <- rnorm(5000), xlab = "x", ylab = "y")
> xylim <- c(range(x), range(y))
> zoom <- function(d, speed = 0.05) {
> rx <- speed * (xylim[2] - xylim[1])
> ry <- speed * (xylim[4] - xylim[3])
> # global assignment '<<-' here!
> xylim <<- xylim + d * c(rx, -rx, ry, -ry)
> plot(x, y, xlim = xylim[1:2], ylim = xylim[3:4])
> NULL
> }
> # Key `+`: zoom in; `-`: zoom out
> # Left, Right, Up, Down: self-explaining
> # `*`: reset
> # Press other keys to quit
> keybd <- function(key) {
> switch(key, `+` = zoom(1), `-` = zoom(-1), Left = zoom(c(-1,
> 1, 0, 0)), Right = zoom(c(1, -1, 0, 0)), Up = zoom(c(0,
> 0, 1, -1)), Down = zoom(c(0, 0, -1, 1)), `*` = plot(x,
> y), "Quit the program")
> }
> getGraphicsEvent(onKeybd = keybd)
> ##
>
> Regards,
> Yihui
> --
> Yihui Xie
> Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
> Mobile: +86-15810805877
> Homepage: http://www.yihui.name
> School of Statistics, Room 1037, Mingde Main Building,
> Renmin University of China, Beijing, 100872, China
>
>
>
> On Thu, Feb 19, 2009 at 7:38 PM, Sklyar, Oleg (London)
> wrote:
> > Two ideas:
> >
> > 1) A library for interactive plots in R
> >
> > R lacks functionality that would allow displaying of
> interactive plots with two distinct functionalities: zooming
> and panning. This functionality is extremely important for
> the analysis of large, high frequency, data sets spanning
> over large ranges (in time as well). The functionality should
> acknowledge Axis methods in callbacks on rescale (so that it
> could be extended to user-specific classes for axis
> generation) and should have a native C interface to R (i.e.
> no Java, but such cross platform widgets like GTK or QT or
> anything similar that does not require heavy-weight add-ons).
> GTK has been used successfully from within R in many
> applications (RGtk, rgobby, EBImage etc) on both *nix and
> Windows, and thus could be a preferential option, it is also
> extremely easy to integrate into R. The existing tools (e.g.
> iplots) are slow, unstable and lack support for time/date
> plots (or actually any non-standard axes) and they are all
> Java. We are looking into stanard xy-plots as well as image
> and 3D plots. Obviously one can think of further
> interactivity, but this would be too much for the Summer of
> Code project. A good prototype would already be a step forward.
> >
> > 2) Cross platform GUI debugger, preferably further Eclipse
> integration (beyond StatET capabilities)
> >
> > Tibco has recently released the S+ workbench for eclipse
> which has a reasonable support for non-command line
> debugging. In the R community, the StatET eclipse plugin
> mimics a lot of code development functionality of S+
> workbench, but has poor support for in-line execution of R
> sessions in eclipse and does not have debugging capabilities.
> Supporting this project further, or developing a GUI debugger
> independent of eclipse, are both acceptable options. The
> debugger should allow breakpoints, variable views etc.
> >
> > For both of the above, our interest is mostly on the Linux
> side, but one should look into cross-platform solutions.
> >
> > Regards,
> > Oleg
> >
> > Dr Oleg Sklyar
> > Research Technologist
> > AHL / Man Investments Ltd
> > +44 (0)20 7144 3107
> > oskl...@maninvestments.com
> >
> >> -Original Message-
> >> From: r-devel-boun...@r-project.org
> >> [mailto:r-devel-boun...@r-project.org] On Behalf Of
Re: [Rd] Google Summer of Code 2009
Oleg, On Feb 19, 2009, at 9:47 , Sklyar, Oleg (London) wrote: Simon, I would not like to take it offline as I disagree with your points and think it is fair to let other users know why. I didn't say offline, I said other thread, since this is not really about GSOC so I think this is getting OT ... To make it clear first, I am most interested in 2D, not 3D plots, and rgobbi is not a good enough solution, unfortunately. 1) I spent loads of time looking for good, if any at all, interactive graphics packages for R. There are hardly many, and apart from rgl there are no good ones as I see it. Maybe we are talking about entirely different things here - rgl is not interactive graphics at all - it is essentially a 3d renderer/viewer, not a data analytic tool [although it can be (ab)used as a very limited one for very specific tasks] - see literature on interactive graphics ... I do accept that this can be subjective, but I think many people will share my opinion. 2) With respect to iplots: http://cran.r-project.org/web/packages/iplots/index.html states: Version:1.1-3 Depends:R (≥ 1.5.0), methods, rJava (≥ 0.5-0) http://www.rosuda.org/iplots/ states: News: * 2007/08/07 Released iplots_1.1-1 on CRAN... There might be version 3 available somewhere, but it is not obvious where and the above one is Java based. I have tried the above version about 4 months ago -- it was slow, unstable and did not have any support for time axis at all. If I find it, I will give it a try and will be able to post corresponding comments. At the very least it is polite to report any such issues (with details) to the authors. Comments like "X is bad, slow and crashes" are completely useless since they are unsubstantiated claims that don't help in creating better software -- neither are they helpful as a starting point for creating new software. If you want to be of any use to the community you should be more specific as of what you are talking about, what are the data examples etc. and talk to the authors. Given your comments I suspect you have very specific ideas of use, but we can only know when you tell us. In general, Java graphics are not slow, in fact they are often faster than conventional "native" implementations and are far more flexible. [[split off to Java for graphics thread if you wish]] As for iPlots, the development has shifted a while ago from the 'old' iPlots to the new ones which are in development stage (as I said they are announced for the useR! conference). My point was not about telling you to use a specific software, it was rather about making you aware of the fact that what you describe already exists (ggobi definitely is IG in GTK) and/or is worked on (iPlots 3.0) with possibly better approach. I do fully support a GSOC proposal for interactive graphics software, it's just I think your formulation included some unnecessarily restricting details and personal opinions as well as misunderstandings as of what interactive graphics are. If we get that right, I think it's a great opportunity. [[only this is really for the GSOC thread]] 2) rggobi is not a solution for 2D graphics at all and this is what is missing in R. I would not mention rgobbi myself having had no look at it first. However, if somebody works on interactive 2D plots, there is no reason why this person should think of 3D as well to have all in one framework. I'll let ggobi authors respond to that, but ggobi is not about 3d at all - in fact 3d is just a very small part of ggobi. Again, I suspect it's not really interactive graphics that you have in mind and/or you are not familiar with it ... [[split off to ggobi thread]] 3) I have a prototype using gtkdatabox for very fast interactive plots in R using GTK, but it is limited by the capabilities of the gtkdatabox widget, not that of R or GTK as such. I don't know about your prototype, so I cannot really comment on that, but gtkdatabox is not IG, either. I do think there is a need for an interactive graphics package for R. I do completely agree with that, but interactive means it satisfies basic requirements on IG such as the availability of selection, highlighting, queries, interactive change of parameters etc. This is not about 2d/3d clouds at all - that we have for decades already. Also this is not about "hacks" to glue on interactivity to existing graphics systems with a chewing gum. We need a versatile (possible extensible) set of interactive statistical plots -- at least that's what our experience shows. Cheers, Simon -Original Message- From: Simon Urbanek [mailto:simon.urba...@r-project.org] Sent: 19 February 2009 14:34 To: Sklyar, Oleg (London) Cc: Friedrich Leisch; r-devel@r-project.org; manuel.eugs...@stat.uni-muenchen.de Subject: Re: [Rd] Google Summer of Code 2009 On Feb 19, 2009, at 6:38 , Sklyar, Oleg (London
Re: [Rd] Google Summer of Code 2009
[ Cool how nobody cared about Fritz' request not to post ideas yet :) ] [ I broadly share Oleg's "wouldn't it be nice to have better plot devices" wish. But I don't think it is a three-month summer target, and it's not on the side of things Fritz / Manuel prefer as it is infrastructure rather than pure statistics ... Then again, maybe we should put that up to a wider discussion. I like 'infrastructure' as R is a platform to me. ] On 19 February 2009 at 09:33, Simon Urbanek wrote: | If primitive 3d scatterplot interactivity is all you want, go with | rggobi. It's GTK and has all this already and much more. However, | ggobi also shows why GTK is not a good choice for general interactive | graphics toolkit - it [GTK] is slow and lacks reasonable graphics | support. OpenGL is IMHO a better way to go since IG don't really | leverage any of the widgets (you get them for free via R widgets | packages anyway) and OpenGL gives you excellent speed, alpha-support | and anti-aliasing etc. I don't want to turn this into an all-out 'vi versus emacs' slugfest but: -- GTk it not the only choice, and I have been very happy with Qt (and Qwt for a simple yet nice plot widget) on both Linux and Windows; I don't have access to a Mac so I didn't test there. -- Qt supports OpenGL natively. The demos are very impressive (for OpenGL as well as the other widgets). -- Deepayan has been working on Qt-based code to enhance R, as that appears to be 'unannounced' I won't post the SVN repo but allow me to state that the code already ran all (or almost all) examples from the lattice book. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] interactive graphics for R: was Google Summer of Code 2009
Dear Simon, thanks for comments. I better give a bit of a background first. We are analysing time series of financial data, often multivariate and with say 200K samples. It is quite a frequent situation that one needs to display multivariate time series of say 200K rows and 10 columns over the whole time range and be able to zoom in to look for effects of interest. The obvious choice of plots is a multiplot window with a shared x-axis, in this case time, zooming should be done simultaneously in all time series displayed. I do understand this is a very specific example, but I am sure similar problems arise in other discilines: think of a genomic browser, sequencing or any other non-financial time series data etc. Essentially, no matter what the graphying or rendering technology used beneath (GTK, QT or anything else), my requirements, and yes they are in a way subjective, but on the other hand quite generic, would be a possibliity to produce multiplot windows (similar to say setting mfrow in par) with two simple features: zooming and panning simultaneously on all plots or independently. The support for Axis/pretty method callbacks is required because those are the methods that provide correct axis labeling independently on the class of the data. This is essentially the only thing that is not supported by the gtkdatabox widget as the rulers can only display numbers. On the other issues of interactivity, I agree it is quite a broad term, but the functionality I describe above is pretty much basic. As for Java objections: this is not because Java is slow on its own, but the interface is not native, requires a huge JVM for a fairly simple task and the interface is relatively slow and cumbersome. As soon as I see a package demonstrating good performance via rJava, I will be happy to say I was wrong. But essentially the same problem with 'playwith' package mentioned earlier -- it uses RGtk, gWidgets and therefore it is slow -- it is not that GTK is slow, but the complex binding from R via RGtk to GTK. If used natively, it is very fast. > As for iPlots, the development has shifted a while ago from > the 'old' > iPlots to the new ones which are in development stage (as I > said they > are announced for the useR! conference). My point was not about > telling you to use a specific software, it was rather about > making you > aware of the fact that what you describe already exists (ggobi > definitely is IG in GTK) and/or is worked on (iPlots 3.0) with > possibly better approach. Where can I find it to have a look? No matter that it is in development, if it fits the needs, I will only be happy to contribute what I can. > > > 3) I have a prototype using gtkdatabox for very fast interactive > > plots in R using GTK, but it is limited by the capabilities of the > > gtkdatabox widget, not that of R or GTK as such. > > > > I don't know about your prototype, so I cannot really comment > on that, > but gtkdatabox is not IG, either. > I cannot send you an example of an R package using gtkdatabox from the office, but I will create a small demo pack at home and will send it to you separately as to indicate what I am looking into. Possibly it is not IG, but this is essentially what I described above, although quite primitive (but it was a one-day project for me, not 3-months). > > > I do think there is a need for an interactive graphics > package for R. > > > > I do completely agree with that, but interactive means it satisfies > basic requirements on IG such as the availability of selection, > highlighting, queries, interactive change of parameters etc. This is > not about 2d/3d clouds at all - that we have for decades > already. Also > this is not about "hacks" to glue on interactivity to existing > graphics systems with a chewing gum. We need a versatile (possible > extensible) set of interactive statistical plots -- at least that's > what our experience shows. Agree completely. > > Cheers, > Simon > > > > > >> -Original Message- > >> From: Simon Urbanek [mailto:simon.urba...@r-project.org] > >> Sent: 19 February 2009 14:34 > >> To: Sklyar, Oleg (London) > >> Cc: Friedrich Leisch; r-devel@r-project.org; > >> manuel.eugs...@stat.uni-muenchen.de > >> Subject: Re: [Rd] Google Summer of Code 2009 > >> > >> > >> On Feb 19, 2009, at 6:38 , Sklyar, Oleg (London) wrote: > >> > >>> Two ideas: > >>> > >>> 1) A library for interactive plots in R > >>> > >>> R lacks functionality that would allow displaying of interactive > >>> plots with two distinct functionalities: zooming and panning. This > >>> functionality is extremely important for the analysis of > >> large, high > >>> frequency, data sets spanning over large ranges (in time as well). > >>> The functionality should acknowledge Axis methods in callbacks on > >>> rescale (so that it could be extended to user-specific classes for > >>> axis generation) and should have a native C interfa
[Rd] Interactive Graphics in R [Was: Google Summer of Code 2009]
On Feb 19, 2009, at 11:20 , Yihui Xie wrote:
Well, for the first idea, isn't it easy enough to fulfill zooming or
panning using getGraphicsEvent() in the grDevices package?
Yes, but that's exactly what interactive graphics are NOT about (you
just posted a good "chewing gum" reference from my previous e-
mail ;)). You can put together ad-hoc hacks (and many have tried it in
R before), but the result will not be general interactive graphics.
What people don't realize is that a lot in IG software is about user
interface and HCI. Having one-shot tools for very specific tasks
doesn't really help to solve the big picture (although it may sort of
solve your specific immediate problem). There are many good
interactive software applications out there, but just linking them to
R is just half of the story.
What we need is a more general framework for interactive graphics -
this requires more than just a graphics subsystem - you have to depart
from the concept of graphics objects and include "statistical objects"
in the mix such that the underlying data/statistics etc. can be
identified by linking back though the graphics. This is something we
still lack in R --- but I hope we will get there sooner or later...
Cheers,
Simon
For example
(using keys +/-/Left/Right/Up/Down/* to zoom and pan):
##
# a demo for zooming and panning in R graphics
# by Yihui Xie Feb 20, 2009
##
# a large number of points
plot(x <- rnorm(5000), y <- rnorm(5000), xlab = "x", ylab = "y")
xylim <- c(range(x), range(y))
zoom <- function(d, speed = 0.05) {
rx <- speed * (xylim[2] - xylim[1])
ry <- speed * (xylim[4] - xylim[3])
# global assignment '<<-' here!
xylim <<- xylim + d * c(rx, -rx, ry, -ry)
plot(x, y, xlim = xylim[1:2], ylim = xylim[3:4])
NULL
}
# Key `+`: zoom in; `-`: zoom out
# Left, Right, Up, Down: self-explaining
# `*`: reset
# Press other keys to quit
keybd <- function(key) {
switch(key, `+` = zoom(1), `-` = zoom(-1), Left = zoom(c(-1,
1, 0, 0)), Right = zoom(c(1, -1, 0, 0)), Up = zoom(c(0,
0, 1, -1)), Down = zoom(c(0, 0, -1, 1)), `*` = plot(x,
y), "Quit the program")
}
getGraphicsEvent(onKeybd = keybd)
##
Regards,
Yihui
--
Yihui Xie
Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086
Mobile: +86-15810805877
Homepage: http://www.yihui.name
School of Statistics, Room 1037, Mingde Main Building,
Renmin University of China, Beijing, 100872, China
On Thu, Feb 19, 2009 at 7:38 PM, Sklyar, Oleg (London)
wrote:
Two ideas:
1) A library for interactive plots in R
R lacks functionality that would allow displaying of interactive
plots with two distinct functionalities: zooming and panning. This
functionality is extremely important for the analysis of large,
high frequency, data sets spanning over large ranges (in time as
well). The functionality should acknowledge Axis methods in
callbacks on rescale (so that it could be extended to user-specific
classes for axis generation) and should have a native C interface
to R (i.e. no Java, but such cross platform widgets like GTK or QT
or anything similar that does not require heavy-weight add-ons).
GTK has been used successfully from within R in many applications
(RGtk, rgobby, EBImage etc) on both *nix and Windows, and thus
could be a preferential option, it is also extremely easy to
integrate into R. The existing tools (e.g. iplots) are slow,
unstable and lack support for time/date plots (or actually any non-
standard axes) and they are all Java. We are looking into stanard
xy-plots as well as image and 3D plots. Obviously one can think of
further interactivity, but this would be too much for the Summer of
Code project. A good prototype would already be a step forward.
2) Cross platform GUI debugger, preferably further Eclipse
integration (beyond StatET capabilities)
Tibco has recently released the S+ workbench for eclipse which has
a reasonable support for non-command line debugging. In the R
community, the StatET eclipse plugin mimics a lot of code
development functionality of S+ workbench, but has poor support for
in-line execution of R sessions in eclipse and does not have
debugging capabilities. Supporting this project further, or
developing a GUI debugger independent of eclipse, are both
acceptable options. The debugger should allow breakpoints, variable
views etc.
For both of the above, our interest is mostly on the Linux side,
but one should look into cross-platform solutions.
Regards,
Oleg
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Friedrich Leisch
Sent: 18 February 2009
Re: [Rd] heatmap without dendrogams (PR#13512)
j.j.goe...@lumc.nl wrote:
> Full_Name: Jelle Goeman
> Version: 2.8.1
> OS: Win XP
> Submission from: (NULL) (87.212.67.197)
>
>
> I get the following error message when I try to make a heatmap (package
> stats),
> without the associated dendrograms.
>
> X <- matrix(rnorm(200),20,10)
> XX <- crossprod(X)
> heatmap(XX, Rowv= NA, revC=TRUE)
> Error in rev(ddr) : object "ddr" not found
> heatmap(XX, Rowv= NA, sym=TRUE)
> Error in heatmap(XX, Rowv = NA, sym = TRUE) : object "ddr" not found
>
> According to the help file, this should work; indeed it does if I set revC or
> sym to FALSE. Seems like ddr should be initialized to something like 1:ncol(X)
> for the no-dendrogram case.
>
> Kind regards,
>
> Jelle
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Since it looks like nobody answered so far, let me suggest a patch:
D:\RCompile\recent\R\src\library\stats\R>diff -u dendrogram.R
dendrogram.R-new
--- dendrogram.R2009-02-19 18:54:18.832062400 +0100
+++ dendrogram.R-new2009-02-19 18:52:29.612961900 +0100
@@ -699,7 +699,7 @@
x <- t(x)
if(revC) { # x columns reversed
iy <- nr:1
-ddr <- rev(ddr)
+if(doRdend) ddr <- rev(ddr)
x <- x[,iy]
} else iy <- 1L:nr
Best wishes,
Uwe Ligges
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bugfix for nls with port algorithm (PR#13540)
Full_Name: Manuel A. Morales
Version: 2.8.1
OS: Linux
Submission from: (NULL) (137.165.199.246)
When fitting a model in nls using the algorithm port with constraints and the
shorthand parameter[factor] in the model, I get the following error message:
"Error in nls_port_fit(m, start, lower, upper, control, trace) :
(list) object cannot be coerced to type 'double'
In addition: Warning message:
In start < low :
longer object length is not a multiple of shorter object length"
This error can be fixed by changing line 423 in nls.R from:
if(any(start < low || start > upp)) {
to:
if(any(unlist(start) < low || unlist(start) > upp)) {
The following code will generate the error:
x = runif(200)
b0 = c(rep(0,100),runif(100))
b1 = 1
fac <- as.factor(rep(c(0,1), each=100))
y = b0+b1*x+rnorm(200,sd=0.05)
nls(y~b0[fac]+b1*x, start=list(b0=c(1,1),b1=1), algorithm="port",
upper=c(100,100,100))
Manuel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bugfix for nls with port algorithm (PR#13540)
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of
> manuel.a.mora...@williams.edu
> Sent: Thursday, February 19, 2009 11:55 AM
> To: r-de...@stat.math.ethz.ch
> Cc: r-b...@r-project.org
> Subject: [Rd] bugfix for nls with port algorithm (PR#13540)
>
> Full_Name: Manuel A. Morales
> Version: 2.8.1
> OS: Linux
> Submission from: (NULL) (137.165.199.246)
>
>
> When fitting a model in nls using the algorithm port with
> constraints and the
> shorthand parameter[factor] in the model, I get the following
> error message:
>
> "Error in nls_port_fit(m, start, lower, upper, control, trace) :
> (list) object cannot be coerced to type 'double'
> In addition: Warning message:
> In start < low :
> longer object length is not a multiple of shorter object length"
>
> This error can be fixed by changing line 423 in nls.R from:
>
> if(any(start < low || start > upp)) {
>
> to:
>
> if(any(unlist(start) < low || unlist(start) > upp)) {
The || should be changed to | or this should be converted
to 2 calls to any() joined by a ||. (I prefer the latter.)
Otherwise you get no notice that your start value is out
of bounds in many cases. E.g., with your data and fix the
following ought to complain:
nls(y~b0[fac]+b1*x, start=list(b0=c(1,-1),b1=101), algorithm="port",
upper=c(100,100,100), lower=c(0,0,0))
Changing that line to
if (any(unlist(start) < low) || any(unlist(start) > upp)) {
makes it give a proper complaint:
> nls(y~b0[fac]+b1*x, start=list(b0=c(1,-1),b1=101), algorithm="port",
+ upper=c(100,100,100), lower=c(0,0,0))
Error in nls(y ~ b0[fac] + b1 * x, start = list(b0 = c(1, -1), b1 =
101), :
Convergence failure: initial par violates constraints
Should '||' and '&&' warn if their arguments are not scalar (or perhaps
0-long also)? The related 'if' does:
> if(c(TRUE,FALSE)) cat("yes\n") else cat("no\n")
yes
Warning message:
In if (c(TRUE, FALSE)) cat("yes\n") else cat("no\n") :
the condition has length > 1 and only the first element will be used
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
>
> The following code will generate the error:
> x = runif(200)
> b0 = c(rep(0,100),runif(100))
> b1 = 1
> fac <- as.factor(rep(c(0,1), each=100))
> y = b0+b1*x+rnorm(200,sd=0.05)
> nls(y~b0[fac]+b1*x, start=list(b0=c(1,1),b1=1), algorithm="port",
> upper=c(100,100,100))
>
> Manuel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bugfix for nls with port algorithm (PR#13540)
> -Original Message-
> From: r-devel-boun...@r-project.org=20
> [mailto:r-devel-boun...@r-project.org] On Behalf Of=20
> manuel.a.mora...@williams.edu
> Sent: Thursday, February 19, 2009 11:55 AM
> To: r-de...@stat.math.ethz.ch
> Cc: r-b...@r-project.org
> Subject: [Rd] bugfix for nls with port algorithm (PR#13540)
>=20
> Full_Name: Manuel A. Morales
> Version: 2.8.1
> OS: Linux
> Submission from: (NULL) (137.165.199.246)
>=20
>=20
> When fitting a model in nls using the algorithm port with=20
> constraints and the
> shorthand parameter[factor] in the model, I get the following=20
> error message:
>=20
> "Error in nls_port_fit(m, start, lower, upper, control, trace) :=20
> (list) object cannot be coerced to type 'double'
> In addition: Warning message:
> In start < low :
> longer object length is not a multiple of shorter object length"
>=20
> This error can be fixed by changing line 423 in nls.R from:
>=20
> if(any(start < low || start > upp)) {
>=20
> to:
>=20
> if(any(unlist(start) < low || unlist(start) > upp)) {
The || should be changed to | or this should be converted
to 2 calls to any() joined by a ||. (I prefer the latter.)
Otherwise you get no notice that your start value is out
of bounds in many cases. E.g., with your data and fix the
following ought to complain:
nls(y~b0[fac]+b1*x, start=3Dlist(b0=3Dc(1,-1),b1=3D101), =
algorithm=3D"port",
upper=3Dc(100,100,100), lower=3Dc(0,0,0))
Changing that line to
if (any(unlist(start) < low) || any(unlist(start) > upp)) {
makes it give a proper complaint:
> nls(y~b0[fac]+b1*x, start=3Dlist(b0=3Dc(1,-1),b1=3D101), =
algorithm=3D"port",
+ upper=3Dc(100,100,100), lower=3Dc(0,0,0))
Error in nls(y ~ b0[fac] + b1 * x, start =3D list(b0 =3D c(1, -1), b1 =
=3D
101), :
Convergence failure: initial par violates constraints
Should '||' and '&&' warn if their arguments are not scalar (or perhaps
0-long also)? The related 'if' does:
> if(c(TRUE,FALSE)) cat("yes\n") else cat("no\n")
yes
Warning message:
In if (c(TRUE, FALSE)) cat("yes\n") else cat("no\n") :
the condition has length > 1 and only the first element will be used
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com=20
>=20
> The following code will generate the error:
> x =3D runif(200)
> b0 =3D c(rep(0,100),runif(100))
> b1 =3D 1
> fac <- as.factor(rep(c(0,1), each=3D100))
> y =3D b0+b1*x+rnorm(200,sd=3D0.05)
> nls(y~b0[fac]+b1*x, start=3Dlist(b0=3Dc(1,1),b1=3D1), =
algorithm=3D"port",
> upper=3Dc(100,100,100))
>=20
> Manuel
>=20
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>=20
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interactive Graphics in R [Was: Google Summer of Code 2009]
> What we need is a more general framework for interactive graphics - this > requires more than just a graphics subsystem - you have to depart from the > concept of graphics objects and include "statistical objects" in the mix > such that the underlying data/statistics etc. can be identified by linking > back though the graphics. This is something we still lack in R --- but I > hope we will get there sooner or later... Well apart from the interactivity, you have that with ggplot2. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interactive Graphics in R [Was: Google Summer of Code 2009]
Simon, as promised I attach a simple package that utilises gtkdatabox. It is Linux only, sorry for that: as it was hacked together in the last two hours I did not have time for Windows stuff. Under my Ubuntu I only had to install libgtkdatabox-dev from standard repos (which would pull libgtk2-dev where necessary). The package relies on gtkdatabox being found under the standard pkg-config path (i.e. custom path installs would be difficult until compiler flags are manually changed). This is for simplicity of ./configure After installing, simply run example(databox) and use your mouse for zooming-in with quite a standard left mouse click for drawing a selection box (a click is required within a selection to zoom in); right mouse click zooms out. I think it is CTRL-right or SHIFT-right to zoom out to full scale. This is a kind of functionality I would like to see. I do not mean the gtkdatabox, but the idea. With this one it is quite easy to add more plots to the window and as the user has control over callbacks it is easy to do autorescale on multiple plots if required. The limitation is the ruler of the gtkdatabox itself (no time), no NA treatment, implementation via increases pix buffer on zoom (rather than off-screen) etc. I do not know if r-devel will allow a tar.gz source through, but if anybody else is interested, please let me know and I will send the source directly. Best, Oleg databox_0.0.1.tar.gz Description: GNU Zip compressed data __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
> On Thu, 19 Feb 2009 11:47:12 +, > Robin Hankin (RH) wrote: > thanks for this clarification Uwe > Could I include the r_env_cache/ directory in the package > and then assume that the CRAN checks use > Sweave( , driver=weaver()) > in which case the process takes about 10 seconds? That makes no sense, because then there are no checks done at all: if the code in your vignette does not change, weaver will not recompute anything, hence the cached results are used. But in that case you could as well include only the PDF (or the generated .tex if you like that better) ... The whole point of checking vignettes on CRAN is that we can track errors due to changes in R or other packages. The second benefit is that users can easily play around with your code and use itr as examples ... how good an example with 10 hour runtime is depends of course on the application. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
On Thu, Feb 19, 2009 at 5:36 PM, Friedrich Leisch wrote: >> On Thu, 19 Feb 2009 11:47:12 +, >> Robin Hankin (RH) wrote: > > > thanks for this clarification Uwe > > Could I include the r_env_cache/ directory in the package > > and then assume that the CRAN checks use > > > Sweave( , driver=weaver()) > > > in which case the process takes about 10 seconds? > > That makes no sense, because then there are no checks done at all: if > the code in your vignette does not change, weaver will not recompute > anything, hence the cached results are used. But in that case you > could as well include only the PDF (or the generated .tex if you like > that better) ... > Unless this has changed recently,I've tried including a PDF but it does not appear in library(help = myPackage) nor on the CRAN site on http://cran.r-project.org/package=myPackage while Sweave'd PDFs do. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interactive Graphics in R [Was: Google Summer of Code 2009]
On Feb 19, 2009, at 16:36 , hadley wickham wrote: What we need is a more general framework for interactive graphics - this requires more than just a graphics subsystem - you have to depart from the concept of graphics objects and include "statistical objects" in the mix such that the underlying data/statistics etc. can be identified by linking back though the graphics. This is something we still lack in R --- but I hope we will get there sooner or later... Well apart from the interactivity, you have that with ggplot2. Ehm - interactivity is the point here ... Cheers, S __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
> On Thu, 19 Feb 2009 10:52:19 -0600, > Dirk Eddelbuettel (DE) wrote: > [ Cool how nobody cared about Fritz' request not to post ideas yet :) ] Well, I kind of expected that ;-) See also below. > [ I broadly share Oleg's "wouldn't it be nice to have better plot devices" > wish. But I don't think it is a three-month summer target, Yes, that's exactly what came to my mind first: As usual, please do read docs before you post ... in this case the format of SOC (I included the link in my original email, googling for "summer of code" will also take you there): a student is paid to code three months for us, the 3 months inlcude writing documentation. The student will not be an expert in R internals, and no magic wizard. The student should familiarize himself with the project before the actual coding period, but there is only so much you can do in limited time. I think you can expect a similar amount of code as in a master/diploma thesis (but NOT a dissertation). If you had waited for Manuels email you would also have learned about another VERY IMPORTANT POINT: The collection of ideas for summer of code is not like writing a list of wishes to Santa Claus (or the Christkind or whatever your local variation may be): we only need ideas which YOU ARE WILLING TO MENTOR, i.e., you write the specs for the project, communicate with students interested in the project, select the best applicant and supervise the student during the coding period. I am not sure everyone on this thread is aware about this (if all of you were I apologize). If you propose an idea, you simultaneously agree to volunteer a considerable amount of your own time. But that time can really be worth the effort (otherwise we wouldn't be doing it). > and it's not on the side of things Fritz / Manuel prefer as it is > infrastructure rather than pure statistics ... Then again, maybe > we should put that up to a wider discussion. I like > 'infrastructure' as R is a platform to me. ] I have no "preference" for pure statistics: last year we had 75% infrastructure ideas and 25% statistics. I simply want to shift the percentages to a more even ratio, because we had many application on the statistical side and I don't want to waste talent. It is also our USP in the summer of code. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] vignette compilation times
> On Thu, 19 Feb 2009 17:47:53 -0500, > Gabor Grothendieck (GG) wrote: > On Thu, Feb 19, 2009 at 5:36 PM, Friedrich Leisch > wrote: >>> On Thu, 19 Feb 2009 11:47:12 +, >>> Robin Hankin (RH) wrote: >> >> > thanks for this clarification Uwe >> > Could I include the r_env_cache/ directory in the package >> > and then assume that the CRAN checks use >> >> > Sweave( , driver=weaver()) >> >> > in which case the process takes about 10 seconds? >> >> That makes no sense, because then there are no checks done at all: if >> the code in your vignette does not change, weaver will not recompute >> anything, hence the cached results are used. But in that case you >> could as well include only the PDF (or the generated .tex if you like >> that better) ... >> > Unless this has changed recently,I've tried including a PDF but it does not > appear in library(help = myPackage) nor on the CRAN site on > http://cran.r-project.org/package=myPackage > while Sweave'd PDFs do. That was not the point of my email: If we process vignettes using the weaver package during check, then in fact no checking is done at all -> the whole purpose of vignettes is circumvented. For vignettes you can be sure that all computations have been done using the latest version of R and the package, i.e., the doc is up to date. For a PDF this is not necessarily the case. There is a good reason why we (more or less gently) try to push people writing docs as Sweave files. It is also unclear to me whether including a PDF without sources in a GPLed package isn't a violation of the GPL (I know people who very strongly think so). And source according to the GPL means "the preferred form of the work for making modifications to it." So for a PDF showing R output that would mean the text plus R code plus data ... which boils down to XXXweave anyway. But we really had this discussion several times ... perhaps somebody volunteers to write an RFC for a more general system of including manuals in R and volunteers to send patches implementing the mechanism afterwards? Note that such a system needs to be compatible with the package metadata system and work on all platforms. Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
On 20 February 2009 at 12:06, Friedrich Leisch wrote: | > On Thu, 19 Feb 2009 10:52:19 -0600, | > Dirk Eddelbuettel (DE) wrote: | | > [ Cool how nobody cared about Fritz' request not to post ideas yet :) ] | | Well, I kind of expected that ;-) | | See also below. | | > [ I broadly share Oleg's "wouldn't it be nice to have better plot devices" | > wish. But I don't think it is a three-month summer target, | | Yes, that's exactly what came to my mind first: As usual, please do | read docs before you post ... in this case the format of SOC (I | included the link in my original email, googling for "summer of code" | will also take you there): a student is paid to code three months for | us, the 3 months inlcude writing documentation. The student will not | be an expert in R internals, and no magic wizard. The student should | familiarize himself with the project before the actual coding period, | but there is only so much you can do in limited time. I think you can | expect a similar amount of code as in a master/diploma thesis (but | NOT a dissertation). | | If you had waited for Manuels email you would also have learned about | another VERY IMPORTANT POINT: The collection of ideas for summer of | code is not like writing a list of wishes to Santa Claus (or the | Christkind or whatever your local variation may be): we only need | ideas which YOU ARE WILLING TO MENTOR, i.e., you write the specs for | the project, communicate with students interested in the project, | select the best applicant and supervise the student during the coding | period. I am not sure everyone on this thread is aware about this (if | all of you were I apologize). If you propose an idea, you | simultaneously agree to volunteer a considerable amount of your own | time. But that time can really be worth the effort (otherwise we | wouldn't be doing it). I am not sure if you're lecturing just to me or the audience at large; if it just me allow me to remind you that I mentored last year and helped to bring a project from proposal to inclusion onto CRAN and into user's hands. In fact, I mentored another one (on cran source to deb package automation) at Debian as well. So yes, I am in fact fully aware of most of these points. I would at this point also like to correct something you said in the earlier mail where you said that may get "four to six slots". I am doubtful about that. O verall number of GSoC slots are _down_ as per Leslie. We have no priors on whether more or less organisations are admitted or not. If I were a betting man, I'd say three to four slots. So let's make them count. Dirk -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Google Summer of Code 2009
> On Thu, 19 Feb 2009 20:25:35 -0600, > Dirk Eddelbuettel (DE) wrote: > On 20 February 2009 at 12:06, Friedrich Leisch wrote: > | > On Thu, 19 Feb 2009 10:52:19 -0600, > | > Dirk Eddelbuettel (DE) wrote: > | > | > [ Cool how nobody cared about Fritz' request not to post ideas yet :) ] > | > | Well, I kind of expected that ;-) > | > | See also below. > | > | > [ I broadly share Oleg's "wouldn't it be nice to have better plot devices" > | > wish. But I don't think it is a three-month summer target, > | > | Yes, that's exactly what came to my mind first: As usual, please do > | read docs before you post ... in this case the format of SOC (I > | included the link in my original email, googling for "summer of code" > | will also take you there): a student is paid to code three months for > | us, the 3 months inlcude writing documentation. The student will not > | be an expert in R internals, and no magic wizard. The student should > | familiarize himself with the project before the actual coding period, > | but there is only so much you can do in limited time. I think you can > | expect a similar amount of code as in a master/diploma thesis (but > | NOT a dissertation). > | > | If you had waited for Manuels email you would also have learned about > | another VERY IMPORTANT POINT: The collection of ideas for summer of > | code is not like writing a list of wishes to Santa Claus (or the > | Christkind or whatever your local variation may be): we only need > | ideas which YOU ARE WILLING TO MENTOR, i.e., you write the specs for > | the project, communicate with students interested in the project, > | select the best applicant and supervise the student during the coding > | period. I am not sure everyone on this thread is aware about this (if > | all of you were I apologize). If you propose an idea, you > | simultaneously agree to volunteer a considerable amount of your own > | time. But that time can really be worth the effort (otherwise we > | wouldn't be doing it). > I am not sure if you're lecturing just to me or the audience at > large; Of course to the audfiance at large, I know that you know the rules of the game. That I answered your email, in the thread was more or less chance. Sorry if I gave a wrong impression (wouldn't have possibly thought that you could feel addressed personally). My sincere apologies!!! > I would at this point also like to correct something you said in > the earlier mail where you said that may get "four to six > slots". I am doubtful about that. O verall number of GSoC slots > are _down_ as per Leslie. We have no priors on whether more or > less organisations are admitted or not. If I were a betting man, > I'd say three to four slots. OK, didn't know that number of slots is down (should probably read the docs better myself). I was assuming that the number of slots is approx the same, and hoping for more slots in the second year (because I know that all organizations get fewer in their first year). Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] How to unload a dll loaded via library.dynam()?
[Moved to R-devel as suggested.]
library.dynam.unload() does work if the OS is cooperative. And if you
have your package set up correctly and unload the namespace (and not
just detach the package if there is a namespace) then the shared
object/DLL will be unloaded. There are examples in several base R
packages (grDevices, grid, methods, splines, stats, tools).
However, there are several instances on Windows (tcltk is one) where
reloading the package DLL does not work, and this seems to be because
dependent DLLs are already loaded and do not run their initializations
correctly. I've not seen problems on Linux. On Solaris reloading a
different shared object of the same name into a process used not to
work (you got the first version under that name): I've not checked
recently.
On Fri, 20 Feb 2009, Gábor Csárdi wrote:
Hmmm, I think restarting R is not a very good solution. It is rather
ugly in the first place. But perhaps even more importantly, it can be
rather inconvenient if one has a large data set in the memory and
needs to save/load it just to reload a package that was updated in the
meanwhile.
This happens to me quite often with 20-40Gb of data, so I would really
love to have a solution for proper detach/unload.
Why not use the one already provided?
Best,
Gabor
On Fri, Feb 20, 2009 at 1:32 AM, Duncan Murdoch wrote:
On 19/02/2009 6:19 PM, Alex F. Bokov wrote:
Hello. To save the hassle of quitting and restarting R every time I
rebuild the package I'm working on (for the purposes of this question called
"roots") I would like to write a script cleanly remove the package from my R
session and then load it again. Of course detach("package:roots") works for
the native R objects in the package. However, the compiled C library remains
loaded. Using library.dynam.unload as documented results in:
Error in library.dynam.unload("roots.so",
"~/R/x86_64-pc-linux-gnu-library/2.8/roots/libs/") :
shared library 'roots' was not loaded
I also tried the above command with the file extension omitted and the
last one and two levels of the directory path omitted. In both cases I still
get the "not loaded" error. I've also Googled the list archives and while
there were several questions like mine, none of them were answered by the
list. Am I to believe that this is something hardly anybody does? Does this
mean everybody sits around waiting for R to start up everytime they make a
minor change to the C source?
If there is a tutorial for doing this, I'd much appreciate the link.
This is more of an R-devel question than R-help, so if this doesn't answer
your question, please follow up there.
On Windows, the following sort of works:
library(rgl)
.dynLibs()
Filename Dynamic.Lookup
1 F:/R/R-2.8.1/library/methods/libs/methods.dll FALSE
2 F:/R/R-2.8.1/library/grDevices/libs/grDevices.dll FALSE
3 F:/R/R-2.8.1/library/stats/libs/stats.dll FALSE
4 F:/R/R-2.8.1/library/rgl/libs/rgl.dll TRUE
library.dynam.unload("rgl", "F:/R/R-2.8.1/library/rgl")
I say "sort of", in that I get no error messages and the dll is no longer
locked in use as it normally would be in Windows, but reloading the package
doesn't function properly. It's possible some combination of detach() and
unloadNamespace() would get a clean unload, but really, I normally just quit
R and restart. It's pretty quick to start up, compared to the recompile
time for the package.
Duncan Murdoch
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
--
Gabor Csardi UNIL DGM
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Interactive Graphics in R [Was: Google Summer of Code 2009]
Hi Simon, Yes I agree with you on the definition of IG (selection, data query, ...), but I only meant to respond to Oleg's "R lacks functionality that would allow displaying of interactive plots with two distinct functionalities: zooming and panning." I thought that was just a problem to adjust the x and y limits, so I posted the "chewing gum" :-) For Oleg: sorry I forgot to mention that currently getGraphicsEvent() only works for Windows screen display. Regards, Yihui -- Yihui Xie Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086 Mobile: +86-15810805877 Homepage: http://www.yihui.name School of Statistics, Room 1037, Mingde Main Building, Renmin University of China, Beijing, 100872, China On Fri, Feb 20, 2009 at 1:38 AM, Simon Urbanek wrote: > > On Feb 19, 2009, at 11:20 , Yihui Xie wrote: > >> Well, for the first idea, isn't it easy enough to fulfill zooming or >> panning using getGraphicsEvent() in the grDevices package? > > Yes, but that's exactly what interactive graphics are NOT about (you just > posted a good "chewing gum" reference from my previous e-mail ;)). You can > put together ad-hoc hacks (and many have tried it in R before), but the > result will not be general interactive graphics. What people don't realize > is that a lot in IG software is about user interface and HCI. Having > one-shot tools for very specific tasks doesn't really help to solve the big > picture (although it may sort of solve your specific immediate problem). > There are many good interactive software applications out there, but just > linking them to R is just half of the story. > > What we need is a more general framework for interactive graphics - this > requires more than just a graphics subsystem - you have to depart from the > concept of graphics objects and include "statistical objects" in the mix > such that the underlying data/statistics etc. can be identified by linking > back though the graphics. This is something we still lack in R --- but I > hope we will get there sooner or later... > > Cheers, > Simon > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
