Two solutions in C++, well-explained
Solutions\n\n#### DP\nIt's quite intuitive to adopt DP to solve this problem: \n\n- sorting the envelopes first via its first value (width)\n- allocating an arr
### Solutions\n\n#### DP\nIt's quite intuitive to adopt DP to solve this problem: \n\n- sorting the envelopes first via its first value (width)\n- allocating an array to record the maximal amount for each envelope (the maximal amount we can get ending with the current envelope)\n\nDirectly the time cost here will be o(nlogn+n^2) which is o(n^2) and meantime taking up o(n) extra space.\n\n```\nint maxenvelopes(vector<pair<int, int>>& envelopes) \n{\n\tint size = envelopes.size();\n\tif(!size) return 0;\n\tsort(envelopes.begin(), envelopes.end());\n\tint maxrolls[size]{0}, maxroll = 1;\n\tmaxrolls[0] = 1;\n\tfor(int i = 1; i < size; ++i)\n\t{\n\t\tmaxrolls[i] = 1;\n\t\tfor(int j = i-1; j >= 0; --j)\n\t\t\tif(envelopes[i].first>envelopes[j].first && envelopes[i].second>envelopes[j].second)\n\t\t\t\tmaxrolls[i] = max(maxrolls[i], maxrolls[j]+1);\n\t\tmaxroll = max(maxroll, maxrolls[i]);\n\t}\n\treturn maxroll;\n}\n```\n\n#### LIS\nActually here we are counting the **longest increasing sequence** as well except there are two dimensions we need to consider. And also we should remember the o(nlogn) solution in LIS, where the essential greedy concept is trying to \n\n1. make the all the elements in the collector as small as possible, especially the last one which is the gate to control the size of the collector - the longest length;\n2. append the bigger ones to the collector;\n\nBut here we need to make some modifications since there are two dimensions to consider. To ensure the two dimensions array can be compressed into one dimension and meantime the requirements of the two conditions above are also properly met, just sorting is not enough here.\n\n- we need to convert this 2-dimentsion problem to a 1-dimension LIS: first sort the array via the width in ascending order and then sort the sub-array with the same width in descending order (the height) then the two conditions in LIS will also be met traversing from the smallest width to the biggest: and the height will be used as that in LIS - the last element will be updated to be as smaller as possible and meantime maintain the envelopes constraint since its width order will always be valid, furthermore the condition 2 is also met just as that in LIS.\n\n> **Note** if we do not sort the sub-arrays (with the same width) in descending order, the LIS in the height is then invalid. Suppose the sub-arrays are also sorted in ascending order, the height in the same width will be appended in our LIS method, wrong result. To sort the heights in the same width in descending order will avoid this case by updating the height in the same width since we are using `lower_bound`.\n\nTime complexity now becomes O(nlogn) taking up O(n) space.\n\n```\nint maxEnvelopes(vector<pair<int, int>>& envelopes) \n{\n\tint size = envelopes.size();\n\tsort(envelopes.begin(), envelopes.end(), [](pair<int, int> a, pair<int, int>b){\n\t\treturn a.first<b.first || (a.first==b.first && a.second>b.second);\n\t});\n\tvector<int> collector;\n\tfor(auto& pair: envelopes)\n\t{\n\t\tauto iter = lower_bound(collector.begin(), collector.end(), pair.second);\n\t\tif(iter == collector.end()) collector.push_back(pair.second);\n\t\telse if(*iter > pair.second) *iter = pair.second;\n\t}\n\treturn collector.size();\n}\n```\n\n##### lower_bound\n- On random-access iterators, logarithmic in the distance between first and last: Performs approximately log2(N)+1 element comparisons (where N is this distance).\n- On non-random-access iterators, the iterator advances produce themselves an additional linear complexity in N on average.\nAlways welcome new ideas and `practical` tricks, just leave them in the comments!
[]