So let's say I have a problem (X) that needs to be solved. Most people in research use several approaches around a sub-topic Y. Most of these algorithms have performance of 80-95% accuracy so there is a space for improvement. I understand that a proper PhD topic would be to find a better solution here.

But what if I just use a new technique (K) to solve this problem? It hasn't been addressed yet in literature. I expect the performance of it to be lower or near the conventional methods. I justify using it because it's outperforming in imagery tasks and it would open up the literature to a new method.

If I use K to solve this problem and get lower performance than conventional solutions Y, does that count as a proper PhD thesis?

In other words, to define a PhD topic, should I find the problem to solve or use a tool and see how it solves a problem?

  • Since you are in the computer science domain, you should think in terms of publications. Using DNN to solve this problem is probably one of those papers. One paper is usually not enough for a good CS PhD. You need a consistent body of work for a PhD and one paper does not cut it. – Alexandros Mar 17 '16 at 16:39
  • You completely misinterpreted my question. – M-T-A Mar 17 '16 at 17:26
  • 4
    How is that? A new technique with a similar (or worse performance) than previous methods might (or might not) give you a single paper. You need more than that. What didn't I understand? – Alexandros Mar 17 '16 at 17:36

The following answer/story is more to address the titular question, and the last line of the OP (free of the context of the rest of the post)...

I once attended a talk by Peter Sarnak. He had the following to say (which I recall from memory; these are not guaranteed to be his exact words) on the matter:

My student had just recently finished solving a problem for his thesis. He was very excited to have found a new way to approach the problem that worked. He said to me,

"Okay, now that I have these new tools, what can I solve with them?"

To which I responded:

"No, no, no! That's not how you do research. You don't pick up tools and then take them to a problem to solve with them. I mean, sometimes you can get lucky that way, so you can try it if you want. But that's not the smart way. What you do is, you pick up a problem and then you invent the tools you need to solve it.

As far as the more specific question of the OP...

Ultimately, this is something to discuss with your advisor. Expecting worse results is not likely to sound very appealing as a project idea, unless you can make a convincing argument that it will make some sort of improvement—be it computation time, memory consumption, cost to implement (maybe it can be run on data obtained by cheaper technology that other methods basically can't), or a basic proof of concept that could lead to more meaningful breakthroughs after suitable adjustments and investigation, etc. If you can do those now, your advisor may decide this could be a fruitful area of investigation.

Either way, talk it out and see what his opinion is, and if he knows if this actually has appeared in the literature before or not.

  • 1
    While I agree in general with the admonition not to go into things with a solution in search of a problem, many productive areas of research have been opened up by "We just invented this new hammer to solve this problem over here. Hmm. I wonder how many other nail-like problems we can use it on." – R.M. Mar 18 '16 at 20:22

Here are my couple of rules that worked for me, students and friends:

What can you publish?: Find an area/sub area first, not the specific topic until you have a publication. For example, I choose the area of code generation, I keep working on it and then when I'm collecting my thoughts and findings to write a publication, I need to put a title on it. That title of the paper becomes my title, lets say: a code generator for the domain of X. If I can't publish more then well that will be my PhD thesis title. However if I keep working on it and then come up with more publications then that would effect my title as well. You see what I'm trying to say here?

Tools: The rule of thumb is that research-based tools developed by researchers are not that good in general. Their quality of code is not that great, and if you put all of your eggs in their basket, then you are risking many things, like time, effort and so on. However, if the tool is developed in your research group so then you can trust it to some extent, because then you can talk to the creators if you hit a problem.

Passion and Problem Not X and Problem: Find a problem that you are passionate about, that you will work couple of years on it; so why not something that you like or love? You did your Bsc and Msc, what topic/problem made you mad? What problem you saw that you think you can solve? Finding an easy path to a problem ends in disaster. You will talk about your problem/solution to other researchers, don't be a lifeless researcher that just roams around and have no passion about his/her topic. Again, you see what I'm saying here?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.