From simon.urbanek at r-project.org  Thu Feb 19 17:46:47 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Thu, 19 Feb 2009 11:46:47 -0500
Subject: [Rd] Google Summer of Code 2009
In-Reply-To: <1A68FCB28DE72F4BA3B967E6506CCE43047DF6A8@mildnpexmb01.maninvestments.ad.man.com>
References: <18844.37238.384954.744812@ridcully.stat.uni-muenchen.de>
	<1A68FCB28DE72F4BA3B967E6506CCE43047DF6A4@mildnpexmb01.maninvestments.ad.man.com>
	<AF924562-B299-47E3-B3A6-83B668D7050F@r-project.org>
	<1A68FCB28DE72F4BA3B967E6506CCE43047DF6A8@mildnpexmb01.maninvestments.ad.man.com>
Message-ID: <DEC00D2A-55A3-465E-AEF4-7B9E29BAA44E@r-project.org>

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.
>

<free-software-author's rant>
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.
</free-software-author's rant>
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.urbanek at r-project.org]
>> Sent: 19 February 2009 14:34
>> To: Sklyar, Oleg (London)
>> Cc: Friedrich Leisch; r-devel at r-project.org;
>> Manuel.Eugster at 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 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
>>> osklyar at maninvestments.com
>>>
>>>> -----Original Message-----
>>>> From: r-devel-bounces at r-project.org
>>>> [mailto:r-devel-bounces at r-project.org] On Behalf Of
>> Friedrich Leisch
>>>> Sent: 18 February 2009 22:54
>>>> To: r-devel at r-project.org
>>>> Cc: Manuel.Eugster at 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 at 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 at 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 only.  It  
> contains information which may be confidential and privileged.  If  
> you are not the intended recipient, please notify the sender  
> immediately, destroy this email and any attachments and do not  
> otherwise disclose or use them. Email transmission is not a secure  
> method of communication and Man Investments cannot accept  
> responsibility for the completeness or accuracy of this email or any  
> attachments. Whilst Man Investments makes every effort to keep its  
> network free from viruses, it does not accept responsibility for any  
> computer virus which might be transferred by way of this email or  
> any attachments. This email does not constitute a request, offer,  
> recommendation or solicitation of any kind to buy, subscribe, sell  
> or redeem any investment instruments or to perform other such  
> transactions of any kind. Man Investments reserves the right to  
> monitor, record and retain all electronic communications through its  
> network to ensure the integrity of its systems, for record keeping  
> and regulatory purposes.
> Visit us at: www.maninvestments.com
> TG0908
> **********************************************************************
>



[Rd] Google Summer of Code 2009
Simon Urbanek