5 ms·

From the preface: > Put a bit more dramatically, [this monograph] will seek to show how problems that were once avoided, having been shown to be NP-hard to sol

From the preface: > Put a bit more dramatically, [this monograph] will seek to show how problems that were once avoided, having been shown to be NP-hard to solve, now have solvers that operate in near-linear time, by carefully analyzing and exploiting additional task structure! This is something I've noticed in my own research on inverse problems (signal recovery over the action of compact groups). And it's really quite mind-blowing. What this means is that you can randomly generate problems, and these will be NP-hard to solve. However, assuming the problem is not randomly generated (i.e., there is some regularity in the generative process that produced the data), there often appears to be some inherent structure that can be exploited to solve the problem quickly to its global optimum. I feel like future research will focus on finding the line that divides the "tractable" problems from the "intractable" ones.

blt 9y ago
I agree. I think we will see an explosion of techniques that exploit prior knowledge about the set of problem instances typically encountered in real life. The prior may come from analysis by hand or be learned from data. We will need to move away from worst-case analyses. Randomized analyses will use more expectations over nontrivial probability distributions instead of uniform distributions over the entire problem space.
BoiledCabbage 9y ago
> I feel like future research will focus on finding the line that divides the "tractable" problems from the "intractable" ones. My gut feeling is there is no "tractable" line. All subsets of problems are tractable. Via analogy, think of auto-encoders or dimensional reduction. You may have 500^2 dimensions representing each pixel in an image recognition task. Representing all of that data in a lower dimensional space is impossible via pigeonhole. But if you only feed your net the subset of images of cats (or dogs, or only images commonly taken on cameras) it's actually a much smaller space and it can be represented efficiently in lower dimensions. And you can take any subset and it will have structure and because it has structure it can be represented more efficiently and solved efficiently. The fact that we're only interested in a subset of the problem space it what makes it efficient for us to solve. Even if we generated "random" pixels, but used a method to only generate a subset of that noise (ie gave it structure), then we'd be able to reduce dimensions on it. There is no line of portion of the space that's tractable or not, it's the fact we're working with a structured portion of the space that always makes it tractable. I think it will be phenomenal when it's finally common place, but I think the comment they're making is "It's amazing that there's this think called compression and it works on, and works well on just about anything we want to compress. I understand theoretically it should make some things larger, but just about everything I try to compress it makes smaller!" Of course, it does because the only things we want to compress are things that have enough inherent structure that we want to save and share them. If all we were interested in were just the output of a random number generator (which wouldn't compress), then we'd never want to compress it anyway. It's phenomenal actually. The only problems it works on are the problems we want to solve. Because the problems we want to solve have structure in them, they follow some rules (which is why we care about them to begin with).
- cs702 9y ago
  I fully agree. However, that still leaves an open problem. To the best of my knowledge there is no good way to measure "tractability," i.e., how much structure a problem has in comparison to other problems. For example, I don't think there is a good way to measure how much more tractable -- i.e., how much more structure there is in -- the problem of classifying dog/cat photos versus the problem of classifying dog/cat/wolf photos versus the problem of classifying fruit/vegetable photos. The various measures of "structure" that we have today (Shannon entropy, algorithmic information content, etc.) fall short for measuring the kind of hierarchical structure (multiple levels of function composition) that is prevalent in high-dimensional problems of interest. Any research that might lead to a good way of measuring "hierarchical structure" (for lack of a better term) seems important to me.
  - BoiledCabbage 9y ago
    > Any research that might lead to a good way of measuring "hierarchical structure" (for lack of a better term) seems important to me. Which is an interesting question. Why is hierarchical structure so important for ML, but not for compression? One view would be, our ML approach is "wrong" and could be improved. In almost all cases running compressed data through another compression scheme yields little to no improvement. Yet in ML we're focused on multiple transforms requiring a concept of hierarchy. Maybe it's because ML is the equivalent of a multi-layered modular compression schemes but in practice all compression is fairly monolithic. If instead we compressed using first a single layer doing key based look up of long identical strings, and then did run-length encoding we'd have items that look more like our ML approach. But, this doesn't intuitively feel right to me. Another view is that ML works in the physical world and the physical world has inherent hierarchical structure. And we don't do this in the digital world of compression. But a counterpoint is that when we program, we exploit hierarchical structure in our code and data via functions, layers and abstraction. Which leads me to think it's the third answer. Compression is lossless, and ML is lossy. Being lossy is what allows hierarchy to work. If you are lossless you can't ever leave working with the lowest level of abstraction or else you're by definition losing/changing information. The command equivalent "Send an email with content X to my sister" is absolutely a lossy summary of what is happening or will happen below the surface. Me giving my computer that command it will translate to different low level actions each time I do it. Similarly if someone asks what command I just ran and I give that description, it isn't enough information for them to recreate a CPU & network packet level exact reproduction of what I did. It is lossy. Machine Learning of "is this a cat?" is exactly like this. By contrast, in compression you have to have every bit recovered. So I think the answer, back to your point, is we may not have an equivalent methodology of discussing information theory / content in a lossy domain. As a result of this we don't have a way of discussing information content in a hierarchical structure as they may be one and the same.
eachro 9y ago
Super curious, what kind of problems do you mean when you say "signal recovery over the action of compact groups"?
- Xcelerate 9y ago
  Consider an object. Now duplicate that object many times, add random noise to each object, and give it a random rotation in space (over the rotation group SO(3)). The goal is to recover the original object from the noisy, rotated copies of it.
gabrielgoh 9y ago
A simple example of this that has been shown rigorously is compressed sensing. Finding the sparsest vector, subject to linear constraints Ax = b is NP hard for general matrices, but is solvable in polynomial time if A satisfies the RIP property (e.g. w.h.p if A is generated by randomly sampling gaussians for each entry). Quite surprising!
- jjgreen 9y ago
  Sadly, that not many A arising in practice have the RIP property.
- mturmon 9y ago
  Another example (that may be related to yours) is the general linear programming problem, that is, for vector x, max c^T x s.t. A x <= b [component-wise] If problem instances (A, b) are chosen at random, from a rotationally-symmetric distribution, Borgwardt and others showed that, with high probability, the number of steps of the solution method is bounded by a polynomial in the number of dimensions. But on the other hand, there are explicit constructions of (A, b) that cause an exponential number of solution steps. The usual interpretation is that "most" problems are friendly to the standard linear programming approach, but a few are not.
JD557 9y ago
> I feel like future research will focus on finding the line that divides the "tractable" problems from the "intractable" ones. IIRC, there's some research about "Phase transitions in Computation Complexity" that seems to be what you are looking for: http://www.lsv.fr/Events/fmt2012/SLIDES/moshevardi.pdf http://www.lsv.fr/Events/fmt2012/SLIDES/moshevardi.pdf (I think I saw that talk at Youtube a long time ago, but I can't find it now)
- 98324298f 9y ago
  might you be thinking of Florent and Lenka Krzakalas research? https://www.youtube.com/watch?v=i0N6mn9L-GA&list=PLvKBgJ4p0p3yNIJfnNx0BA4EKAHg3eOT- https://www.youtube.com/watch?v=i0N6mn9L-GA&list=PLvKBgJ4p0p...
tw1010 9y ago
This is a really great observation. A lot of the time when people say "but that problem is NP!" is it still likely that you'd be able to solve it by exploiting some structural properties of the specifics.
faragon 9y ago
In this context: Tractable problem = generalization from previous knowledge. Intractable problem = not enough previous knowledge.
wenc 9y ago
This has been known for a while now, and I would suggest it's not so much about "tractable" vs "intractable" problem classes. It's important to understand what NP-hard means -- it doesn't mean exponential complexity, but worst case exponential complexity (a theoretical bound). It means there's always the possibility we will hit the worst case, but it doesn't mean we always do. If you exploit structure and apply heuristics, you can achieve very good average case performance. In fact, we have been solving NP-hard problems in mission-critical environments quite efficiently for many years now. Take the case of Mixed Integer Linear Programs (MILP) -- that is, Linear Programs (LPs) with integer variables. It is well known that they are NP-hard. However, modern solvers (CPLEX, Gurobi) implement a whole bunch of heuristics and techniques that make solver performance extremely good on most problems. MILPs are used to do large-scale planning, routing, etc. and industry relies on MILP solutions every day. MILP solvers today are 10^9 times faster than in 1991, and most of that speedup owes firstly to algorithmic breakthroughs, and secondly to machine improvements. It's astounding. https://www.fields.utoronto.ca/programs/scientific/11-12/bc65/rbixby.pdf https://www.fields.utoronto.ca/programs/scientific/11-12/bc6... That said, MILPs remain NP-hard, which means there's always a chance you will run into cases where the solution will take exponential time to solve (full enumeration). It's an escapable property of this problem class. But the take-home is: NP-hardness does not inherently mean intractability in general.

blt 9y ago

I agree. I think we will see an explosion of techniques that exploit prior knowledge about the set of problem instances typically encountered in real life. The prior may come from analysis by hand or be learned from data. We will need to move away from worst-case analyses. Randomized analyses will use more expectations over nontrivial probability distributions instead of uniform distributions over the entire problem space.

BoiledCabbage 9y ago

> I feel like future research will focus on finding the line that divides the "tractable" problems from the "intractable" ones. My gut feeling is there is no "tractable" line. All subsets of problems are tractable. Via analogy, think of auto-encoders or dimensional reduction. You may have 500^2 dimensions representing each pixel in an image recognition task. Representing all of that data in a lower dimensional space is impossible via pigeonhole. But if you only feed your net the subset of images of cats (or dogs, or only images commonly taken on cameras) it's actually a much smaller space and it can be represented efficiently in lower dimensions. And you can take any subset and it will have structure and because it has structure it can be represented more efficiently and solved efficiently. The fact that we're only interested in a subset of the problem space it what makes it efficient for us to solve. Even if we generated "random" pixels, but used a method to only generate a subset of that noise (ie gave it structure), then we'd be able to reduce dimensions on it. There is no line of portion of the space that's tractable or not, it's the fact we're working with a structured portion of the space that always makes it tractable. I think it will be phenomenal when it's finally common place, but I think the comment they're making is "It's amazing that there's this think called compression and it works on, and works well on just about anything we want to compress. I understand theoretically it should make some things larger, but just about everything I try to compress it makes smaller!" Of course, it does because the only things we want to compress are things that have enough inherent structure that we want to save and share them. If all we were interested in were just the output of a random number generator (which wouldn't compress), then we'd never want to compress it anyway. It's phenomenal actually. The only problems it works on are the problems we want to solve. Because the problems we want to solve have structure in them, they follow some rules (which is why we care about them to begin with).

cs702 9y ago
I fully agree. However, that still leaves an open problem. To the best of my knowledge there is no good way to measure "tractability," i.e., how much structure a problem has in comparison to other problems. For example, I don't think there is a good way to measure how much more tractable -- i.e., how much more structure there is in -- the problem of classifying dog/cat photos versus the problem of classifying dog/cat/wolf photos versus the problem of classifying fruit/vegetable photos. The various measures of "structure" that we have today (Shannon entropy, algorithmic information content, etc.) fall short for measuring the kind of hierarchical structure (multiple levels of function composition) that is prevalent in high-dimensional problems of interest. Any research that might lead to a good way of measuring "hierarchical structure" (for lack of a better term) seems important to me.
- BoiledCabbage 9y ago
  > Any research that might lead to a good way of measuring "hierarchical structure" (for lack of a better term) seems important to me. Which is an interesting question. Why is hierarchical structure so important for ML, but not for compression? One view would be, our ML approach is "wrong" and could be improved. In almost all cases running compressed data through another compression scheme yields little to no improvement. Yet in ML we're focused on multiple transforms requiring a concept of hierarchy. Maybe it's because ML is the equivalent of a multi-layered modular compression schemes but in practice all compression is fairly monolithic. If instead we compressed using first a single layer doing key based look up of long identical strings, and then did run-length encoding we'd have items that look more like our ML approach. But, this doesn't intuitively feel right to me. Another view is that ML works in the physical world and the physical world has inherent hierarchical structure. And we don't do this in the digital world of compression. But a counterpoint is that when we program, we exploit hierarchical structure in our code and data via functions, layers and abstraction. Which leads me to think it's the third answer. Compression is lossless, and ML is lossy. Being lossy is what allows hierarchy to work. If you are lossless you can't ever leave working with the lowest level of abstraction or else you're by definition losing/changing information. The command equivalent "Send an email with content X to my sister" is absolutely a lossy summary of what is happening or will happen below the surface. Me giving my computer that command it will translate to different low level actions each time I do it. Similarly if someone asks what command I just ran and I give that description, it isn't enough information for them to recreate a CPU & network packet level exact reproduction of what I did. It is lossy. Machine Learning of "is this a cat?" is exactly like this. By contrast, in compression you have to have every bit recovered. So I think the answer, back to your point, is we may not have an equivalent methodology of discussing information theory / content in a lossy domain. As a result of this we don't have a way of discussing information content in a hierarchical structure as they may be one and the same.

eachro 9y ago

Super curious, what kind of problems do you mean when you say "signal recovery over the action of compact groups"?

Xcelerate 9y ago
Consider an object. Now duplicate that object many times, add random noise to each object, and give it a random rotation in space (over the rotation group SO(3)). The goal is to recover the original object from the noisy, rotated copies of it.

gabrielgoh 9y ago

A simple example of this that has been shown rigorously is compressed sensing. Finding the sparsest vector, subject to linear constraints Ax = b is NP hard for general matrices, but is solvable in polynomial time if A satisfies the RIP property (e.g. w.h.p if A is generated by randomly sampling gaussians for each entry). Quite surprising!

jjgreen 9y ago
Sadly, that not many A arising in practice have the RIP property.
mturmon 9y ago
Another example (that may be related to yours) is the general linear programming problem, that is, for vector x, max c^T x s.t. A x <= b [component-wise] If problem instances (A, b) are chosen at random, from a rotationally-symmetric distribution, Borgwardt and others showed that, with high probability, the number of steps of the solution method is bounded by a polynomial in the number of dimensions. But on the other hand, there are explicit constructions of (A, b) that cause an exponential number of solution steps. The usual interpretation is that "most" problems are friendly to the standard linear programming approach, but a few are not.

JD557 9y ago

> I feel like future research will focus on finding the line that divides the "tractable" problems from the "intractable" ones. IIRC, there's some research about "Phase transitions in Computation Complexity" that seems to be what you are looking for: http://www.lsv.fr/Events/fmt2012/SLIDES/moshevardi.pdf http://www.lsv.fr/Events/fmt2012/SLIDES/moshevardi.pdf (I think I saw that talk at Youtube a long time ago, but I can't find it now)

98324298f 9y ago
might you be thinking of Florent and Lenka Krzakalas research? https://www.youtube.com/watch?v=i0N6mn9L-GA&list=PLvKBgJ4p0p3yNIJfnNx0BA4EKAHg3eOT- https://www.youtube.com/watch?v=i0N6mn9L-GA&list=PLvKBgJ4p0p...

tw1010 9y ago

This is a really great observation. A lot of the time when people say "but that problem is NP!" is it still likely that you'd be able to solve it by exploiting some structural properties of the specifics.

faragon 9y ago

In this context: Tractable problem = generalization from previous knowledge. Intractable problem = not enough previous knowledge.

wenc 9y ago

This has been known for a while now, and I would suggest it's not so much about "tractable" vs "intractable" problem classes. It's important to understand what NP-hard means -- it doesn't mean exponential complexity, but worst case exponential complexity (a theoretical bound). It means there's always the possibility we will hit the worst case, but it doesn't mean we always do. If you exploit structure and apply heuristics, you can achieve very good average case performance. In fact, we have been solving NP-hard problems in mission-critical environments quite efficiently for many years now. Take the case of Mixed Integer Linear Programs (MILP) -- that is, Linear Programs (LPs) with integer variables. It is well known that they are NP-hard. However, modern solvers (CPLEX, Gurobi) implement a whole bunch of heuristics and techniques that make solver performance extremely good on most problems. MILPs are used to do large-scale planning, routing, etc. and industry relies on MILP solutions every day. MILP solvers today are 10^9 times faster than in 1991, and most of that speedup owes firstly to algorithmic breakthroughs, and secondly to machine improvements. It's astounding. https://www.fields.utoronto.ca/programs/scientific/11-12/bc65/rbixby.pdf https://www.fields.utoronto.ca/programs/scientific/11-12/bc6... That said, MILPs remain NP-hard, which means there's always a chance you will run into cases where the solution will take exponential time to solve (full enumeration). It's an escapable property of this problem class. But the take-home is: NP-hardness does not inherently mean intractability in general.