19

I'm pretty sure almost all mathematicians have been in a situation where they found an interesting problem; they thought of many different ideas to tackle the problem, but in all of these ideas, there was something missing—either the "middle" part of the argument or the "end" part of the argument. They were stuck and couldn't figure out what to do.

  1. In such a situation what do you do?
  2. Is the reason for the "missing part" the incompleteness in the theory of the topic that the problem is related to? What can be done to find the "missing part"?

For tenure-track/tenure professors, maybe this is not a big deal because they have "enough" time and can let the problem "stew" in the "back-burner" of their mind, but for limited time positions, for example, PhD, postdoc, etc., where the student/employee has to prove their capability to do "independent" research, so that they can be hired for their next position. I think for these people it is quite a bit of a problem, because they can't really afford to spend a "lot" of time thinking about the same problem.

I'm particularly interested in the answer in the realms of mathematics, but I would like hear suggestions from "non-mathematicians" as well.

6

7 Answers 7

28
  1. Consider successively more special cases of the problem until you find one that you can solve. Work with the typical example instead of the general case.

  2. Consider more general cases of the problem. Yes, sometimes proving a more general statement is easier than proving a very specific one.

  3. Change the question. Just because you set out to solve a certain problem does not mean you need to stick to this plan. If you found a plausible technique that just doesn't fit your intended application, find a different application that it does fit and pretend this was your plan all along.

  4. Zoom out. Consider the problem in a wider context. Think about what it is that you are really trying to do when you abstract away from the details. Instead of thinking in terms of technical details, think in terms of analogies. For example: what I need in my proof is to find the correct analogue of hypermodular widgets on finite simple groups in the context of locally compact groups.

  5. Talk to people about your problem.

  6. Take a break.

  7. Talk to more people about your problem.

1
  • 3
    Nice list, I would add read (I kept a bibliography of what I read so it made it easy to pop them in to my dissertation/research if needed) and keep a list of research ideas, maybe every month go through your list and add new ideas, variants, or other thoughts.
    – gns100
    Feb 6 at 21:25
17

First, you need to understand that not every math problem is tractable, and many more are not going to be solvable in a fixed time period. Some aren't "ripe" enough in the general course of things for it to be likely that insight will occur, though strange things can happen.

If you work on only the Riemann Hypothesis, you are likely to fail, though you'd be famous if you succeed. The time between the statement and published proof of Fermat's Last Theorem was over 350 years.

For tractable problems, a "vacation" from the problem, even if for an hour or two (or overnight) can sometimes (sometimes!) help. But for truly difficult things, the field might even need to mature for a while and a lot of collaborative discussion might be needed.

So, what you do, when really stuck is to move on to one of your other, hopefully many, lines of inquiry that might result in something that will advance your career while the hard problem "ripens".

Keep a notebook of things that seem interesting and might be followed up in the future. It isn't quite "work in progress", but "future possibilities". Review this notebook periodically and make notations to it if you have gained any insight. Turn to it when you need to set some other project aside, or finish another project.

And, when you leave a problem for an extended period, don't forget to record any partial insights you have when you set it aside. That is, it goes into your future work notebook.

8

Give up and work on a different problem.

I have in my files (some paper some electronic) notes on about twice as many abandoned projects as I have papers. And these are only the ones that got far enough for me to have extensive notes. Counting the problems I've thought about seriously at all, I'm probably batting .050 or so.

It's generally possible to write (and publish) a survey paper on what you learned to work on the problem, or a paper on your partial results. The survey paper can be helpful if well-written; the partial results paper probably not. Either could be used to satisfy bureaucrats counting papers, but research mathematicians are unlikely to give either much weight.

2
7

I usually have multiple related strands of a project going on at the same time. I will focus on most promising one, but if that stalls I switch to the next most promising. That can be difficult, especially if you already spent a lot of time on a given attempt. However, as you already mentioned, in an early career position you cannot afford to beat your head against the same wall over and over again. The reassuring part is that I found that very often the work I have done in those abandoned strands often came back as useful at a later point in time for another project.

1

Generic answer, not specific to maths problems. But it should help a little.

When you are stuck on a problem, do any part you know how to do, then look at the overall problem once more.

If you run out of areas you know how to do, then go looking in "the usual sources" for possible methods to approach it. Textbooks on the subject. Also web pages, journal articles, etc. Requests for hints from colleagues.

If this cycle gets stuck, then consider alternate approaches. That is, completely different methods of solving the problem.

Sometimes a "brute force" method can give you a hint as to the more elegant results. For example, if you were doing an integral. (I know, but it's something I know how to do.) You could do things like solving a simplified version for practice. Or you could do some numerical work to get an idea what the closed form should look like. When solving differential equations you can use tricks like "solution generation" to get solutions to "nearby" versions of the equation that may give you hints. There will be similar things that can be done in your actual research work.

Some folks may not know what I mean by "solution generation." Suppose you have to solve a differential equation that looks like so.

y" = f(x,y)

Suppose that the actual f() you are working with is resisting your efforts. As a practice run, choose a different f() that is not drastically different to yours, but that has a closed form solution you already know. That may give you some hints what the answer to your problem is.

1
  • 2
    This is maybe a dangerous answer for students working on research. Basically when you are working on something like a homework set you can start with the assumptions that a) all problems in the set are solvable, b) all problems in the set are solvable with the tools introduced up to this point. With a research question, 1) the problem may not be solvable at all, 2) if solvable, it may only be solvable with some entire branch of math which hasn't been invented yet, 3) even if solvable with existing tools it may require some specialized thing that you yourself have never heard of. Feb 7 at 17:51
1

Explain the problem to your dog. Sometimes the solution will jump out at you.

1

I would break down the parts of the system or function that you are already confident in and create a visual diagram of it, see how the parts interact, and the "missing bit" might just jump out at you.

I would create a few diagrams of your function or system, and I would follow some kind of universal diagramming tool to make it easy, like UML.

Because I'm a software engineer I need to create hugely complex system with no way to hold the whole system in my head at once, I need to break it down into bitesize pieces from a high level all the way down to the minutia. I would approach understanding a system in the same way though, whether it's software, a social system, a maths problem, they're all just "systems" that have components that interact.

That said, I would create a hierarchy of "Component" diagrams with an "Activity" diagram for each component. The system itself is a Component so make a top level activity diagram for that too.

The point is to break down what is a huge problem into smaller parts, define how the parts interact and then you can work on one part at a time.

Hope this inspires you :)

EDIT: Just came across "Category Theory" which looks like a mathsy flavour of UML, should help you map out your missing bits :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .