blog 06: new post - #12
Conversation
|
requested changes marked by line number |
nick-bors
left a comment
nick-bors
left a comment
There was a problem hiding this comment.
I just reviewed the writing; the typesetting I'm passing to Anthony.
Overall very interesting article and i think it deserves a space and i only really had questions (perhaps for future work) and minor re-wording comments. Good job. :)
|
|
||
| > ### TL;DR | ||
| > [Longest path problem](https://en.wikipedia.org/wiki/Longest_path_problem) has no known "fast" | ||
| > algorithm (unless [P=NP](https://en.wikipedia.org/wiki/P_versus_NP_problem)), but approximations suffice in practice. |
| Held-Karp's complexity grows as $$ \mathcal{\text{O}}(2^\text{N} \cdot \text{N}) $$. Which means that at 30 | ||
| nodes, the program would consume over 100 GB of RAM. | ||
| Of course, there are certain low-level optimizations. One example is capping the maximum number of nodes to 64 | ||
| and storing stuff inside a `uint64_t`. However, all those modifications don't render the program fundamentally faster. |
There was a problem hiding this comment.
Nitpick: I mean they would make it faster but it wouldn't change the inherent scaling characteristics. Its like a constant term in the big O. Also, as much as we drop constants in the big O notation, they really matter i mean what if this algorithm is best (if you're willing to sacrifice some ram) for smaller graphs? if at any point it would beat out brute force or the NN thats something that would be quite interesting
c0532d3 to
9ef42c2
Compare
3 participants
No description provided.