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 <xieyi...@gmail.com> 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 <xieyi...@gmail.com> > 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) > <oskl...@maninvestments.com> 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) 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 > >> Ludwigstraße 33 > >> D-80539 München > >> http://www.statistik.lmu.de/~leisch > >> -------------------------------------------------------------- > >> --------- > >> Journal Computational Statistics --- http://www.springer.com/180 > >> Münchner R Kurse --- http://www.statistik.lmu.de/R > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > > ********************************************************************** > > 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 > > > ********************************************************************** 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