Re: [recommenders-dev] A student interested in GSoC 2013 project idea

[Rushabh Mehta <rm764@xxxxxxxxxxx>]

Hey Andreas,

Thanks a lot for your detailed reply. I highly appreciate it. Thanks to that I have a much clear idea about the project now.

So as I understand it, a lot depends on the context of the code. There are recommendation engines already in place, the challenge is to aggregate the rankings obtained from each so that end result is best suitable and most convenient for the programmer.  

Just wanted you opinion on this : How about having a model (meta-recommender, as you call it) which will tailor/sort the list according to the user?

Should I go ahead with the proposal or would you like to have some background tasks done from me?

Date: Wed, 17 Apr 2013 13:10:36 +0200
From: Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>
To: recommenders-dev@xxxxxxxxxxx
Subject: Re: [recommenders-dev] A student interested in GSoC 2013
        project idea
Message-ID: <516E832C.20305@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

Hello Rushabh,

> I am Rushabh Mehta, currently pursuing Masters of Engineering in
> Computer Science at Cornell University. My interest lies in Machine
> Learning, Information Extraction and Natural Language Processing. I have
> also worked for recommendation based project.
>
> Majorly I code in Java, but I will be happy to learn other technologies
> if needed. These projects seemed very interesting to me because it is at
> the cross-section of Recommendation Engines (ML's application) & Eclipse
> (which is one software which I've used the most)! Successful
> implementation of these ideas will make developer's life a lot easier,
> so with the help of this project I will be able to give back to the
> community :)

great to see you interested in this!

> I had a question about 'Proposal Ranking'. In bug report I found that
> this idea is currently in prototype phase with few Java interfaces
> written down. I am trying to understand the code, but what should be my
> next steps ideally? What would you prefer more : Rigorous analysis about
> different schemes for ranking OR getting existing bugs fixed?

If you say "Rigorous analysis about different schemes for ranking", are
you thinking about different recommender engines/ML algorithms? If so,
then I'm afraid that's not what this proposal is about. (But please read
on.) What this proposal is about instead is how to integrate a whole
range of recommendation engines (writing them is beyond the scope of
this project) within Eclipse's single code completion window.

If one recommender states "The type String is 0.65 important" and
another recommender states "The method getName() is 0.12 important",
then how should these proposals be ranked in a single window/list? This
is a challenge if there is an extensible and possible quite large set of
recommendation engines which a) propose different things (e.g., types,
methods) and whose metrics cannot be compared (in the above, the exact
semantics of 0.65 and 0.12 depends a lot on the engines's ML algorihtms).

Even if the metrics where easily comparable, most programmers would
probably find a list

  String
  getName()
  Date
  getStreet()
  List
  getCity()

more confusing than

  getName()
  getStreet()
  getCity()
  String
  Date
  List

So, there are many factors contributing to a good ranking. Presenting
the results in terms of "blocks" (first methods, then types) is one of them.

Now, here's one idea how to bring these necessary features and your
interest in machine learning together:

While "blocks" are certainly a useful concept, the underlying problem is
that in many situations it is legal to insert both a Type and a method
and that code completion does not know which one the programmer actually
wants.

  void doSomething() {
     $ // trigger code completion here
  }

Do I want to have a type or a method (either on "this" or a statically
imported one) completed here? The programmer probably knows this already
(you rarely hit Ctrl+Space without knowing whether you want a type or a
method), but Eclipse doesn't; thus, it presents you with types *and*
methods in one long list -- which is far from optimal.

Now, if you could predict (with some accuracy) based on the current
context whether a type or a method is more likely, you could reorder the
blocks accordingly, thus saving the programmer time to scroll down to
the block he wanted all along. So, essentially you would have one
meta-recommender which recommends the recommender most likely to apply
in the current context.

Does this sound like an interesting take on the proposal to you?

Best regards,

Andreas
--
Codetrails UG (haftungsbeschr?nkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Regards,

Rushabh Mehta,
www.linkedin.com/in/mehtarushabh


+1 607 262 6760